OHT 1.

Chapter 1
The software quality challenge

• The uniqueness of software quality assurance

• The environments for which SQA methods
are developed
• (significantly modified by R. Roggio, Fall 2011)

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.2
Introduction
• Why Quality Assurance?
• With all the methodology wars, numerous
processes, huge number of tools to assist in
software development, why this separate topic?
• What makes it important that it deserves separate
treatment?
• Why do so many companies add disclaimers to
their software?
– Don’t warranty the documentation…
– Not responsible for direct, indirect, consequential, loss?

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.3
What we are after;
that is, we want to be able to:
• 1. Identify the unique characteristics of software as a
product and as process that justify separate treatment of its
quality issues.
• 2. Recognize the characteristics of the software
environment where professional software develepment
and maintenance take place

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.4

uniqueness / differences between a S

Product and an Industrial Product
• High complexity
– The potential ways in which a software product can be
used with different data / data paths reflecting different
incoming data is almost infinite.
– Manner in which industrial products can be used are
usually well-defined.
– Think about software: every loop with different values
of data reflects a different opportunity to see software
fail.

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.5

niqueness / differences between a So

oduct and an Industrial
• Invisibility of the product
Product (mor
– In an industrial product, missing parts are obvious.
• Something missing? Easily identified.
– Not so in software products.
• May not be noticeable for years – if at all!
• Cite: phantom paths product at AFDSDC!

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.6

niqueness / differences between a So

duct and an Industrial Product (still m
• Opportunities to detect defects (“bugs”)??
• Consider:
– Product Development
– Product Planning
– Product Manufacturing
–

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.7

niqueness / differences between a So

duct and an Industrial Product (still m
• Product Development:
– Industrial: test product; voltages; performance;
strength; size; ….ready to distribute to markets
– Computer Software: once prototype and system testing
are concluded, product is ready for deployment
• About the same approach
• Arguable: equal chance to discover defects?
– What do YOU think??

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.8

niqueness / differences between a So

Product and an industrial Product
Product Production Planning:
– Industrial: Often need new tooling approaches,
assembly lines, new manufacturing processes.
• Results in additional ‘looks’ at products
• One could say that there is a better chance to discover defects
– Computer Software: No real additional ‘look-see.’
• Packages shrink-wrapped, printed, distributed to public
• No real chance to discover additional defects.

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.9

niqueness / differences between a So

Product and an industrial Product
Product Manufacturing:
– Industrial: Usually defects uncovered here; easily fixed.
• Typical burn-in problems; another view of product; stabilizes.
• These represent additional opportunities to discover defects.
– Computer Software:
• We merely copyright, print copies of software and manuals
• No real chance for additional quality views
• No real chance for discovering additional defects

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.10
Only Chance to Discover Defects:
• Best chance to really detect defects occurs
during the software development process itself!
• “The need for special tools and methods for the software
industry is reflected in the professional publications as well in
special standards devoted to SQA, such as ISO 9000-3,
“Guidelines for the application of ISO 9001 to the development,
supply, and maintenance of software.”
• Another: ISO 9004-2: “Quality Management and Quality
Systems Elements: Guidelines for the Services.”

• These characteristics of software – complexity, invisibility, and

limited opportunity to detect bugs has led to the development of
the ISO Guidelines and an awareness of real SQA methodology.

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.11
2. The characteristics of the
SQA environment process
• Important to note that quality issues seem to center around
software development professional activities undertaken
by development and maintenance organizations vice an
individual.
• Quality issues govern professional software development.
• This is our focus: large scale development rather than
individual application development

• Here are some of our main environmental issues:

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.12

2. The characteristics of the

SQA environment process
• Being contracted
• Subjection to customer-supplier relationship
• Requirement for teamwork
• Need for cooperation and coordination with other
development teams
• Need for interfaces with other software systems
• Need to continue carrying out a project while the team
changes
• Need to continue maintaining the software system for years

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.13
SQA Environment
• Being Contracted:
– Professional software development is almost always
contracted.
• Have requirements / supplied requirements (hopefully)
– But may have in-house customer representatives.
– Or, customer representatives available…
• Budget
• Time schedule

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.14
SQA Environment

• Subject to Customer-Supplier Relationship

– In professional software development, there is a
constant (hopefully) oversight between customer and
developer.
• Changes will occur;
• Criticisms will arise.
• Cooperation is critical to overall project success.

– Customer availability / relationship is essential and

often problematic whether reps are in-house or not.

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.15
SQA Environment
• Required Teamwork
– We need teams due to
• Time required for development.
– Workload is too much for a single person
• A frequent variety of experts needed
– Database; networking; algorithms; …
• Need ‘independent’ reviews to ensure quality (me)

– Who is ‘on the team?’

• Developers
• Clients / customers
• Others???

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.16
SQA Environment

• Cooperation and Coordination with Other

Software Teams
– May be partially outsourced thus requiring cooperation
• Outsourced  overseas?
• Many potential problems here … and benefits.
– Laision?
– May be that specialized hardware requires cooperation.
– Other teams may have developed similar software for
the client and can offer tremendous help.

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.17

Cooperation and coordination

scheme for a software
development project team

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.18
SQA Environment

• Interfaces with Other Systems

– Interface, link to, import, include other packages
containing, say, libraries of perhaps classes / packages
to assist in development.
– Standardization considerations in interfaces
– May need to cooperate with inputs coming from other
systems and outputs requiring special formats that serve
as inputs to other systems…
– Do you think Billing, Payroll, Accounts Payable are all
distinct systems???

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.19

Example: Salary software system - an

example of software interfaces

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.20
SQA Environment

• Need to Continue Project despite Team Changes

– Team members leave, are hired, fired, take unexpected
vacations, transferred within the company, and more.
– Maddening truism, but the development must continue.
– You can count on disruption!

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.21
SQA Environment

• Need to continue Software Maintenance for an

Extended Period
– Whether external customers or in-house customers,
follow-on maintenance is typical and for many years!!
– Highly desirable from management/enterprise
perspective
• SQA must address development, operations, and
maintenance! (next chapter)

Galin, SQA from theory to implementation © Pearson Education Limited 2004

Software Quality
Factors

1
The need for a comprehensive
software quality requirements
„ There are some characteristic common :
… All the software projects satisfactory fulfilled the basic
requirements for correct calculations
… All the software projects suffered from poor performance
in important areas such as maintenance, reliability,
software reuse, or training.
… The cause for the poor performance of the developed
software projects in these areas was the lack of predefined
requirements to cover these important aspects of the
software’s functionally.

2
The need for a comprehensive
definition of requirements (2)
„ There is a need for a comprehensive
definition of requirements that will cover all
attributes of software and aspects of the
usability aspects, reusability aspects,
maintainability aspects, and so forth in
order to assure the full satisfaction of the
users.

3
Classification of software requirements
into software quality factors
„ The classic model of software quality
factors suggest by :
… McCall (consist of 11 factors, 1977)
… Deutsch and Willis (consist of 12 to 15 factors,
1988)
… Evans and Marciniak (1987)

4
McCall’s Factor Model

„ Classifies all software requirement into 11

software quality factors, grouped into three
categories :
1. Product operation factors : Correctness,
Reliability, Efficiency, Integrity, Usability.
2. Product revision factors : Maintainability,
Flexibility, Testability.
3. Product transition factors : Portability,
Reusability, Interoperability.

5
Product Operation
Factors

6
Product Operation : Correctness
„ Correctness requirements are defined in a list of the
software system’s required outputs.
„ Output specifications are usually multidimensional;
some common dimensions include :
o The output mission
o The required accuracy of output
o The completeness of the output information
o The up-to-dateness of the information
o The availability of the information
o The standards for coding and documenting the software
system.
7
Product Operation - Reliability
„ Reliability requirements deal with failures to provide service.
„ Determine the maximum allowed software system failures
rate, and can refer to the entire system or to one or more of
its separate functions.
„ Examples :
1. The failures frequency of a heart-monitoring unit that will operate in a
hospital’s intensive care ward is required to be less than one in 20
years. Its heart attack detection function is required to have a failure
rate of less than one per million cases.
2. One requirement of the new software system to be installed in the
main branch of Independence Bank, which operates 120 branches, is
that it will not fail, on average, more than 10 minutes per month
during the bank’s office hours.

8
Product Operation - Efficiency

„ Efficiency requirements deal with the hardware

resources needed to perform all the functions of the
software system in conformance to all other
requirements.
„ Examples :
1. A chain stores is considering two alternative bids for a
software system.

9
Product Operation - Integrity
„ Integrity requirements deal with the software
system security, that is requirements to present
access to an authorize person,
[to distinguish between the majority of personnel allowed to see the
information (“read permit”) and a limited group who will be allowed to
add and change data (“write permit”), and so forth.]

„ Example :
GIS SW allowed citizens access to its GIS through Internet only for viewing
and copying data but not to insert changes.

10
Product Operation - Usability
„ Usability requirements deal with the scope of staff resources
needed to train a new employee and to operate the software
system.
„ Example :
The software usability requirements document for the new
help desk system initiated by a home appliance service
company lists the following specifications :
a. A staff member should be able to handle at least 60 service
calls a day
b. Training a new employee will take no more than two days,
immediately at the end of which the trainee will be able to
handle 45 service calls a day.

11
Product Revision
Factors

12
Product Revision software Quality
Factors
„ According to the McCall model of software quality
factors, three quality factors comprise the product
revision category. These factors deal with those
requirements that affect the complete range of
software maintenance activities :
o Corrective maintenance
o Adaptive maintenance
o Perfective maintenance

13
Product Revision - Maintability
„ Maintainability requirements determine the efforts that will
be needed by users and maintenance personnel to identify the
reasons for software failures, to correct the failures, and to
verify the success of the corrections.
„ This factor’s requirements determine refer to the modular
structure of software, the internal program documentation,
and the programmer’s manual, among other items.
„ Example typical maintainability requirements :
a. The size of a software module will not exceed 30 statements.
b. The programming will adhere to the company coding standards
and guidelines.

14
Product Revision - Flexibility

„ The capabilities and efforts required to support

adaptive maintenance activities are covered by the
flexibility requirements.
„ These include the resources (in man-days) required to
adapt a software package to a variety of customers of
the same trade, of various extents of activities, of
different ranges of products, and so on.
„ This factor’s requirements also support perfective
maintenance activities.
15
Product Revision - Testability
„ Testability requirements deal with the testing
of an information system as well as with its
operation.
„ Testability requirements for the ease of testing
are related to special features in the programs
that help the tester, for instance by providing
predefined intermediate results and log files.

16
Product Transition
Factors

17
Product Transition - Portability
„ Portability requirements tend to the
adaptation of software system to other
environenments consisting of different
hardware, different operating systems, and so
forth.

18
Product Transition - Reusability
„ Reusability requirements deal with the
use of software modules originally
designed for one project currently being
developed.

19
Product Transition -
Interoperability
„ Interoperability requirements focus on
creating interfaces with other software systems
or with other equipment firmware.
„ Interoperability requirements can specify the
name of the software or firmware for which
interface is required.

20
Alternative Models of Software
Quality Factors
„ Formal comparison of the alternative
models (Evans M 1987, Deutsch & Willis
1988)
… Comparison of the factors models-content
analysis (verifiability, expandability, safety,
manageability, survivability)
… Structure of the alternative factor models

21
Who is interested in the definition
of quality requirements?
„ Some quality factors not included in the typical
client’s requirements document may, in many cases,
interest the developer.
„ The following lists of quality factors usually interest
the developer whereas they may raise very little
interest on the part of the client :
o Portability
o Reusability
o Verifiability

22
Requirements Documents
A project will be carried out to according to
two requirements documents :
¾ The client’s requirements document
¾ The developer’s additional requirements
document

23
Software Compliance with
Quality Factors
„ The software’s product compliance to the
requirements belonging to the various quality
factors is measured by software quality metrics,
measures that quantify the degree of
compliance.
„ In order to allow for valid measurements of
compliance, sub-factors have been defined for
those quality factors that represent a wide range
of attributes and aspects of software use.

24
Factors and sub-factors

25
Factors and sub-factors (cont.)

26
Factors and sub-factors (cont.)

27
Software Quality Assurance (SQA) consists of the means to
ensure the quality of the released software by monitoring the
software engineering methods and processes. SQA spans across
the entire software development lifecycle that includes
requirements management, software design, coding, testing, and
release management.

Software Quality Assurance Components

The software quality assurance has the following six classes of
components:

Pre-project Components
The pre-project components ensure that the resources required
for the project, the schedule, and the budget is clearly been
defined. The plan for development and ensuring quality has been
clearly determined. The components are as follows:
• Development plan
• Quality plan
• Schedules
• Required resources (Hardware & Human resources)
• Risk evaluations
• Project methodology

Project lifecycle components

A project lifecycle is usually comprised of two stages. The first
one is the development stage and then comes the operation-
maintenance stage. In the development stage, SQA components
help to identify the design and programming errors.
The SQA components for the operation-maintenance stage
include the development lifecycle components along with
specialized maintenance components aimed to improve the
maintenance tasks.
The project lifecycle components include:
• Reviews
• Expert opinions
• Software testing
• Software maintenance
• Sub-contractors quality assurance

Infrastructure error prevention and improvement

components
The main goal of these components is the prevention of software
faults and minimizes the rate of errors. These components
include:
• Procedure & work instructions
• Templates & checklists
• Staff training, retaining & certification
• Preventive & corrective actions
• Configuration management
• Documentation control

Software quality management components

This class of components consists of controlling the
development and maintenance activities. These components
establish the managerial control of software development
projects. The management control aims to prevent the project
from going over budget and behind schedule.
The management control components include:
• Project progress control
• Software quality metrics
• Software quality costs

Standardization, certification, and SQA assessment

components
The components aim to implement international managerial and
professional standards within the organization.  These
components help to improve the coordination among the 
organizational quality systems and establish standards for the
project process.  The components include:
• Quality management standards
• Project process standards

Organizing for SQA – the human components

The main aim of this class of components is to initiate and
support the implementation of SQA components, identify any
deviations from the predefined SQA procedures & methods and
recommend improvements. The SQA organizational team
includes test managers, testers, SQA unit, SQA committee, and
SQA forum members.
The Main Considerations affecting the use of SQA Components

1. Organizational considerations

a. Type of software development clientele

b. Type of software maintenance clientele

c. Range of software products

d. Size of the organization

 e. Degree and nature of cooperation with other organizations
carrying out related projects

f. Optimization objectives

2. Project and maintenance service considerations

a. Level of complexity and difficulty

b. Degrees of experience with the project technology

c. Extent of software reuse in the new projects

3. Professional staff considerations

a. Professional qualifications

b. Level of acquaintance with team members