Software quality - Definition IEEE
1.
2.
The degree to which a system, component,
or process meets specified requirements.
The degree to which a system, component,
or process meets customer or user needs or
expectations.
1
Software Quality Pressman’s def.
Conformance to explicitly stated functional and performance
requirements, explicitly documented standards, and implicit
characteristics that are expected of all professionally
developed software.
2
Software Quality Assurance The IEEE Definition

1.
2.
SQA is :
A planned and systematic pattern of all actions
necessary to provide adequate confidence that
an item or product conforms to established
technical requirements.
A set of activities designed to evaluate the
process by which the products are developed
or manufactured. Contrast with quality control.
3
IEEE SQA definition – exclude the
maintenance & timetable and budget issues.

The Author adopts the following :

SQA should not be limited to the development process.
It should be extended to cover the long years of service
subsequent to product delivery. Adding the software
maintenance functions into the overall conception of
SQA.

SQA actions should not be limited to technical aspects
of the functional requirements, It should include
activities that deal with scheduling and timetable and
budget .
4
SQA – Expanded Definition
A systematic, planned set of actions necessary to provide
adequate confidence that the software development process or
the maintenance 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 confines.
This definition corresponds strongly with the concepts at the
foundation of ISO 9000-3, 1997
and also corresponds to the main outlines of the CMM for
software
See the Table 2.2 page 27
5
Software Quality Assurance Vs. Software Quality Control

Quality Control : a set of activities designed to evaluate
the quality of a developed or manufactured product. It take
place before the product is shipped to the client.

Quality Assurance : the main objective is to minimize the
cost of guaranteeing quality by a variety of activities
performed throughout the causes of errors, and detect and
correct them early in the dev. Process.
6
The objectives of SQA activities
see page 29

Software development ( process-oriented )

Software maintenance ( Product-oriented )
7
SQA Vs Software Engineering

1.
SW Engineering ( IEEE def. )
The application of a systematic,
restricted, quantifiable approach to
the development and maintenance
of SW; that is the application of
engineering to software.
8
Chapter 3
Software Quality Factors
9
SQ. Factors

From the previous chapters we have already
established that the requirements document is
one of the most important elements for achieving
SQ.

What is a “Good” SQ requirements document ?
10
The need for comprehensive SQ
requirements



Our Sales IS seems v. good , but it is frequently fails,
at least twice a day for 20 minutes or more.( SW house
claims no responsibility….
Local product contains a SW and every thing is ok,
but, when we began planning the development of a
European version, almost all the design and
programming will be new.
etc see page 36.
11
There are some characteristics common to
all these buts :
All SW projects satisfactorily fulfilled the basic
requirements for correct calculations.
 All SW projects suffered from poor performance in
important areas such as maintenance, reliability, SW
reuse, or training.
 The cause for poor performance of the developed SW
projects in these areas was lack of predefined
requirements to cover these important aspects of the
SW functionality.
 The solution is :
The need for a comprehensive definition of requirements
( SQ Factors )

12
Classification of SW requirements into SW
quality factors.


McCall’s Factor Model
This model classifies all SW requirements into 11 SW quality
factors, grouped into 3 categories:
 Product operation: Correctness, Reliability, Efficiency,
Integrity, Usability
 Product revision : Maintainability, Flexibility, Testability
 Product transition : Portability, Reusability,
Interoperability.
See the McCall model of SW quality factors tree
see page 38
13
Product operation SW quality factors

Correctness: Output specifications are usually
multidimensional ; some common include:







The output mission
The required accuracy
The completeness
The up-to-dateness of the info.
The availability of the info.( the reaction time )
The standards for coding and documenting the SW system
See Example page 39.
14
Product operation SW quality factors
Reliability:
Deals with failures to provide service. They determine the
maximum allowed SW system failure rate, and can refer to
the entire system or to one or more of its separate
functions.
See examples page 39 ( heart-monitoring unit )

15
Product operation SW quality factors
Efficiency:
Deals with the HW resources needed to perform all the
functions of the SW system in conformance to all other
requirements.
See examples page 40 ( CPU speed .. etc )
 Integrity:
Deals with the SW system security, that is requirements to
prevent access to unauthorized persons.
See examples page 40

16
Product operation SW quality factors
Usability:
Deals with the scope of staff resources needed to train a new
employee and to operate the SW system.
See examples page 41

17
Product revision SW quality factors
Maintainability :
Maintainability requirements determine the efforts that will
be needed by users and maintenance personnel to
identify the reasons for SW failures, to correct the
failure, and to verify the success of the corrections.
Example : Typical maintainability requirements:
1.
The size of a SW module will not exceed 30 statements
2.
The programming will adhere to the company coding
standards and guidelines.

18
Product revision SW quality factors
Flexibility :
The capabilities and efforts required to support adaptive
maintenance activities are covered by flexibility
requirements. This factor’s requirements also support
perfective maintenance activities, such as changes and
additions to the SW in order to improve its service and
adapt it to changes in the firm’s technical or commercial
environment.
Example :page 42

19
Product revision SW quality factors

-
-
-
Testability :
Deal with the testing of an IS as well as with its
operation.
Providing predefined intermediate results and log files.
Automatic diagnostics performed by the SW system
prior starting the system, to find out whether all
components of SW system are in working order.
Obtain a report about detected faults.
Example :page 42, 43
20
Product transition SW quality factors
Portability :
Tend to the adaptation of a SW system to other
environments consisting :

-
Different HW
Different OS
Example : SW designed to work under windows 2000 env. Is
required to allow low-cost transfer to Linux.
-
21
Product transition SW quality factors

-
-
Reusability :
Deals with the use of SW modules originally designed
for one project in a new SW project currently begin
developed.
The reuse of SW is expected to save resources., shorten
the project period, and provide higher quality modules.
These benefits of higher quality are based on the
assumption that most SW faults have already been
detected by SQA activities performed previously on it.
22
Product transition SW quality factors
Interoperability :
Focus on creating interfaces with other SW systems or
with other equipment firmware.
Example:

-
-
The firmware of medical lab. equipment is required to process
its results according to a standard data structure that can be then
serve as input for a number of standard laboratory IS.
23
Alternative Models Of SW Quality Factors

Two other models for SQ factors:



Evans and Marciniak 1987 ( 12 factors )
Deutsch and Willis 1988. ( 15 factors )
Five new factors were suggested





Verifiability
Expandability
Safety
Manageability
Survivability
24
Alternative Models Of SW Quality Factors

Five new factors were suggested





Verifiability: define design and programming features that enable
efficient verification of the design and programming ( modularity,
simplicity, adherence to documentation and prog guidelines. )
Expandability: refer to future efforts that will be needed to serve
larger populations, improve services, or add new applications in order
to improve usability.
Safety: meant to eliminate conditions hazardous to equipment as a
result of errors in process control SW.
Manageability: refer to the admin. tools that support SW modification
during the SW development and maintenance periods.
Survivability: refer to the continuity of service. These define the
minimum time allowed between failures of the system, and the
maximum time permitted for recovery of service.
25
Who is interested in the definition of quality
requirements ?


The client is not the only party interested in defining
the requirements that assure the quality of the SW
product.
The developer is often interested also specially :




Reusability
Verifiability
Porotability
Any SW project will be carried out according to 2
requirements document :


The client’s requirements document
The developer’s additional requirements document.
26