The document discusses software quality factors and McCall's quality factors model. McCall's model classifies software quality requirements into 11 factors across 3 categories: product operation, product revision, and product transition. Product operation factors include correctness, reliability, efficiency, integrity, and usability. Product revision factors are maintainability, flexibility, and testability. Product transition factors are portability, reusability, and interoperability. The document provides examples to illustrate each quality factor. Alternative models from other authors that expand on McCall's 11 factors are also mentioned.

1. 1
Chapter 3
Software Quality Factors

2. 2
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 ?

3. 3
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 )

4. 4
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:How well it runs…. Correctness, Reliability,
Efficiency, Integrity, Usability
 Product revision :How well it can be changed, tested, and
redeployed.
Maintainability, Flexibility, Testability
 Product transition :How well it can be moved to different
platforms and interface with other systems
Portability, Reusability, Interoperability.

5. List of McCall’s Quality Criteria :
1.Access Audit : Ease with which the software and data can be checked for compliance with
standards.
2.Access Control : Provisions for control and protection of the software
3.Accuracy : Precisions of computations and output.
4.Completeness: Degree to which full implementation of required functionalities have been
achieved.
5.Communicativeness : Ease with which the inputs and outputs can be assimilated.
6.Conciseness : Compactness of the source code, in terms of lines of code.
7.Consistency : Use of uniform design and implementation techniques.
8.Data commonality : Use of standard data representation.
9.Error tolerance : Degree to which continuity of operation is ensured under adverse
conditions.
10.Execution efficiency : Run time efficiency of the software.
11.Expandability : Degree to which storage requirements or software functions can be
expanded.
12.Hardware independence : Degree to which a software is dependent on the underlying
hardware.
13.Modularity : Provision of highly independent modules.
14.Operability : Ease of operation of the software.
15.Simplicity : Ease with which the software can be understood.
16.Software efficiency : Run time storage requirements of the software.
17.Traceability : Ability to link software components to requirements.
18.Training : Ease with which new users can use the system.
5

6. Mccall’s Quality Factors
6

7. 7
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
EX: Specifying the timeliness of the output (time
between event and its consideration by the software
system)

8. 8
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.
System, application,computational failure recovery,
hardware
recovery
Example specs:
– A heart monitoring system must have a failure rate of less than one per
million cases

9. 9
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. Storage,power,communication….
Example spec: simply very slow
communications
 Integrity: acess control,audit
Deals with the SW system security, that is requirements to
prevent access to unauthorized persons.
Huge nowadays; Cyber Security; Internet
security; network security, and
more. These are certainly not the same!

10. 10
Product operation SW quality factors
 Usability:
Operability,training
Deals with the scope of staff resources needed to train a new
employee and to operate the SW system.
Example spec: A staff member should be able to process n
transactions / unit time. (me)

11. 11
Product revision SW quality factors
 Maintainability : simplicity, modularity,document
accessibility, coding compilance
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.

12. 12
Product revision SW quality factors
 Flexibility : modularity,generality,self
descriptiveness
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.
Different clients exercise software differently. This is big!

13. 13
Product revision SW quality factors
 Testability : user ,failure maintence ,traceability
- 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.

14. 14
Product transition SW quality factors
 Portability : software system
independence,modularity
- 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.

15. 15
Product transition SW quality factors
 Reusability : modularity,simplicity,doc accessibilty
- 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.

16. 16
Product transition SW quality factors
 Interoperability : compatability,commanality
- 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.

17. 17
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

18. 18
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.

19. 19
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
 Portability
 Any SW project will be carried out according to 2
requirements document :
 The client’s requirements document
 The developer’s additional requirements document.

20. Models
20