Software Quality assurance

(SQA) - SWE 401

Software Quality Factors

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

Outline
• The need for comprehensive software quality requirements
• Classification of requirements into software quality factors
• Product operation factors
• Product revision factors
• Product transition factors
• Alternative models of software quality factors
• Who is interested in defining quality requirements?
• Software compliance with quality factors

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

After completing this chapter, you will
be able to:
• Explain the need for comprehensive requirements documents
and characterize the contents of such documents.
• Explain the structure (categories and factors) of McCall’s
classic factor model.
• Identify who is interested in the definition of quality
requirements.

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

 “Our new sales information system seems okay, the invoices
are correct, the inventory records are correct, the discounts
granted to our clients exactly follow our very complicated
discount policy, BUT our new sales information system
frequently fails, usually at least twice a day, each time for
twenty minutes or more. Yesterday it took an hour and half
before we could get back to work . . . . Imagine how
embarrassing it is to store managers . . . . Softbest, the
software house that developed our computerized sales
system, claims no responsibility . . . .”

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

“Believe it or not, our software package ‘Blackboard’ for
school teachers, launched just three months ago, is already
installed in 187 schools. The development team just
returned from a week in Hawaii, their vacation bonus. But
we have been suddenly receiving daily complaints from the
‘Blackboard’ maintenance team. They claim that the lack of
failure detection features in the software, in addition to the
poor programmer’s manual, have caused them to invest
more than the time estimated to deal with bugs or adding
minor software changes that were agreed as part of
purchasing contracts with clients.”

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

 “The new version of our loan contract software is really
accurate. We have already processed 1200 customer
requests, and checked each of the output contracts. There
were no errors. But we did face a severe unexpected
problem – training a new staff member to use this software
takes about two weeks. This is a real problem in customer
departments suffering from high employee turnover . . . . The
project team says that as they were not required to deal with
training issues in time, an additional two to three months of
work will be required to solve the problem.”

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

There are some characteristic common to
all these “but’s”:
● All the software projects satisfactorily 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
functionality.

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

The need to a quality requirements
document
• A software quality is based on the quality of its Requirement
Documentation (Specification).
• Many software applications fail because the requirements
document quality is poor.
• The need for improving poor requirements documents is
widespread.

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

Need for Comprehensive Software Quality
Requirements
• Frequently lack quality factors such as: usability, reusability,
maintainability, …
• Software industry groups the long list of related attributes into
what we call quality factors. (Sometimes non-functional
requirements)
• Natural to assume an unequal emphasis on all quality factors.
• Emphasis varies from project to project
– Scalability; maintainability; reliability…

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

Extra Thoughts
• Seems like in Software Engineering we concentrate on
capturing, designing, implementing, and deploying with
emphasis on functional requirements.

• Little (not none!) emphasis on the non-functional

requirements (quality factors).

• Non-functional requirements are captured in the Software

Requirements Specification (SRS); functional requirement
usually captured in Use Case stories.

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

 We need what is called software quality
factors that is included in requirements
document

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

There are different software quality factors and models.
The classic software quality factory model is

McCall software quality

factor

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

 McCall's software quality factors
model

Software quality factors

Product operation factors

Product revision factors

Product transition factors

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

1. Product operation factors

● Correctness
● Reliability
● Efficiency
● Integrity
● Usability

How well does it run and ease of use.

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

1. Product operation factors
● Correctness: Extent to which a program fulfills its
specification.
Examples:
● Specifying accuracies for correct outputs at, say, NLT <1%
errors, that could be affected by inaccurate data or faulty
calculations;
● Specifying the completeness of the outputs provided, which can
be impacted by incomplete data
● Specifying the timeliness of the output (time between event and
its consideration by the software system)
● Specifying the standards for coding and documenting the
software system.

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

1. Product operation factors
● Reliability: Ability not to fail.
Example:
● A heart monitoring system must have a failure rate of less than one per
million cases.
● Downtime for a system will not be more than ten minutes per month.

● Efficiency: Deals with the hardware resources needed to

perform the functions of the software.

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

1. Product operation factors
● Integrity: Protection of the program from
unauthorized access.

● Usability: Ease of use of the software.

Example:
● A staff member should be able to process n transactions / unit time.

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

1. Product operation factors

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

2. Product revision factors

● Maintainability
● Flexibility
● Testability

Can I fix it easily, retest, version it, and deploy it easily?

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

2. Product revision factors
● Maintainability:
○ The degree of effort needed to identify reasons (find the
problem) for software failure and to correct failures and
to verify the success of the corrections.
○ Deals with the modular structure of the software, internal
program documentation, programmer manuals

Example:
● size of module <= 30 statements.

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

2. Product revision factors
● Flexibility: Ease of making changes required by
changes in operating environment.

● Testability: Ease of testing the program to ensure

that it is error-free and meets its specification.

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

2. Product revision factors

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

3. Product transition factors

● Portability
● Reusability
● Interoperability

Can I move the app to different hardware? Interface easily with

different hardware / software systems; can I reuse major
portions of the code with little modification to develop new
apps?

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

3. Product transition factors
● Portability: Effort required to transfer a program
from one environment to another system.

● Reusability: Ease of re-using software in a different

context.

● Interoperability: Effort required to couple a system

to another system.

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

3. Product transition factors

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

Quality Categories Quality Factors Broad Objectives
Correctness Does it do what the customer wants?
Reliability Does it do it accurately all of the time?

Product operation Efficiency Does it quickly solve the intended pro…?

Integrity Is it secure?
Usability Can I run it?
Maintainability Can it be fixed?

Product revision Flexibility Can it be changed?

Testability Can it be tested?
Portability Can it be used on another machine?

Product transition Reusability Can part of it be reused?

Interoperability Can it interface with another system?

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

McCall's factor model tree

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

Alternative Models of SQA
• Boehm Model (1978)

• FURPS Model (1987)

• Evans and Marciniak’s Model (1987)

• Deutsch and Willis’s Model (1988)

• Dromey’s Model (1995)

• GEOQUAMO Model (2003)

• ISO/IEC 25010:2011 (2011)

• AOSQUAMO Model (2012)

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

ISO/IEC 25010:2011 Quality Model
• Developed by a joint ISO/IEC international professional

team
• Composed of eight factors

• Four out of 5 are included in McCall’s Model

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

ISO/IEC 25010:2011 Quality Model
• Functional Suitability

• Performance efficiency

• Compatibility

• Usability

• Reliability

• Security

• Maintainability

• Portability
Galin, SQA from theory to implementation © Pearson Education Limited 2004
1. Functional Suitability
• The capability to fulfill the functions needed by the

customer, stated or implied

• Covers wide aspects of software use including accurate

and complete.
• A significant similarity between the functional suitability

and Correctness, integrity, and interoperability in

McCall’s Quality Model.

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

2- Performance Efficiency
• Amount of Hardware resources required to fulfill the

software system tasks

• A significant similarity between the performance

efficiency and efficiency, in McCall’s Quality Model.

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

3. Compatibility
• Capability to:

• Exchange information with other software systems or

components

• Perform other system required functions, sharing its hardware

and software

• A significant similarity between the Compataboility and

interoperability, in McCall’s Quality Model

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

4- Security
• Capability to Control access.

• A significant similarity between the security and

integrity, in McCall’s Quality Model

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

Alternative factor models
• The two factor models from the late 1980s, alternatives to the
McCall classic factor model, are:
• The Evans and Marciniak factor model.
• The Deutsch and Willis factor model.
• Totally five new factors were suggested.
• Evans and Marciniak offer two ‘new’ ones:
• Verifiability and Expandability
• Deutsch and Willis offer three ‘new’ ones.
• Safety, Manageability, and Survivability.

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

McCall's factor model and alternative
models

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

Criteria for evaluation of software
quality
Examples:
• Flight software that flies on a single mission satellite will
not be concerned with portability but may be very
concerned with reliability.
• A software system that remains on the ground may be
concerned with portability and not very concerned by
reliability.

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

How Does McCall factors improve
quality?
• McCall quality factors could be used as a reference when
preparing requirements document. Most, if not all, of those
factors should be covered explicitly in the software
requirements document.
• Using Quality factors will improve requirements document by
including all details and specifications
• Measuring those factors tell us where we need improvement.
We can use quality metrics

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

Software quality factors in requirements
document
Correctness
• Employees salaries should not be late (Wrong)
• Employees salaries should be calculated accurately and must be ready
five days before the end of the month (Correct)

Reliability
• The system should be working as much time as possible (Wrong)
• The system should not be in failure status during working hours (9 to
4). Total time of failure status should not exceed 20 minutes per
month. (Correct)

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

Software quality factors in requirements
document
Efficiency
• The GPS application should use as little as possible of mobile phone
battery. (Wrong)
• The GPS application should not use more than 10% of battery power in
two hours time. (Correct)

Integrity
• Students should be allowed to access their final marks. (Wrong)
• Students should be allowed to view their final marks. They should not
be able to make any changes. (Correct)

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

Software quality factors in requirements
document
Usability
• The billing system should be easy to use. (Wrong)
• Billing staff should be able to learn the most important five functions of
the billing system in 3 working hours. (Correct)

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

So, Who Cares?
• Both developers and clients need to care. One group may care
more than the other for certain quality factors.

• Certainly the nature of the app dictates more concern on some

of these factors than others (safety, for example)

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

Summary
• The need for comprehensive requirements documents and
their contents.
• The structure (categories and factors) of McCall’s classic
factor model.
• The additional factors suggested by alternative factor models.
• Those interested in defining software quality requirements.

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

Exercise

GO back to the three stories in the

beginning of this presentation
What software quality factors are missing?
Review Questions
1. What are the three factor categories belonging to McCall’s factor
model?

2. What factors are included in each of the categories?

3. What differentiates the Evans and Marciniak model from the

Deutsch and Willis model?
Review Questions
4. Southcottage Inc. is a manufacturer of washing machines and
dishwashers. The requirements document for the new control unit
included the following specifications:
i. The firmware should be suitable for all six variations of
model 2002 washing machines.
ii. The water level control module of the washing machine
should be suitable for use as a water level control module
in the new model 2002 dishwasher.
b. To which of the factors do the above requirements belong?
c. Explain your answer.
Review Questions
Requirement (a) refers to flexibility in the use of a complete firmware
product that by its very design will enable it to be used as firmware in
several variations of washing machines by using a variety of parameter
sets.
Requirement (b) refers to the reuse of part of a firmware product, to a
module that is introduced into entirely different firmware products and
saves the efforts of developing a new module, which will only serve
dishwashers.