Software Quality

Engineering
Ch # 3: Software quality factors
 McCall’s factor model
The 11 factors are grouped into three categories – product operation,
product revision and product transition – as follows:
• Product operation factors: Correctness, Reliability, Efficiency,
Integrity, Usability.
• Product revision factors: Maintainability, Flexibility, Testability.
• Product transition factors: Portability, Reusability, Interoperability.
 3.4 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.
 Maintainability
• 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.
 Flexibility
• The capabilities and efforts required to support adaptive maintenance
activities are covered by the flexibility requirements.
• This factor’s requirements also support perfective maintenance
activities, such as changes and additions to the software in order to
improve its service and to adapt it to changes in the firm’s technical or
commercial environment.
 Testability
• Testability requirements related to software operation include
automatic diagnostics performed by the software system prior to
starting the system, to find out whether all components of the software
system are in working order and to obtain a report about the detected
faults.
 3.5 Product transition software quality factors
• According to McCall, three quality factors are included in the product
transition category, a category that pertains to the adaptation of
software to other environments and its interaction with other software
systems.
 Portability
• Portability requirements tend to the adaptation of a software system to
other environments consisting of different hardware, different
operating systems, and so forth.
Example
• A software package designed and programmed to operate in a
Windows 2000 environment is required to allow low-cost transfer to
Linux and Windows NT environments.
 Reusability
• Reusability requirements deal with the use of software modules
originally designed for one project in a new software project currently
being developed.
• The reuse of software is expected to save development resources,
shorten the development period, and provide higher quality modules.
 Interoperability
• Interoperability requirements focus on creating interfaces with other
software systems or with other equipment firmware
• Interoperability requirements can specify the name(s) of the software or
firmware for which interface is required
Example
• The firmware of a medical laboratory’s equipment is required to process its
results (output) according to a standard data structure that can then serve as
input for a number of standard laboratory information systems.
3.6 Alternative models of software quality factors
Two factor models, appearing during the late 1980s, considered to be
alternatives to the McCall classic factor model (McCall et al., 1977),
deserve discussion:
• The Evans and Marciniak factor model (Evans and Marciniak, 1987).
• The Deutsch and Willis factor model (Deutsch and Willis, 1988).
3.6.1 Formal comparison of the alternative models
• Both alternative models exclude only one of McCall’s 11 factors,
namely the testability factor.
• The Evans and Marciniak factor model consists of 12 factors that are
classified into three categories.
• The Deutsch and Willis factor model consists of 15 factors that are
classified into four categories.
Continue…
Taken together, five new factors were suggested by the two alternative
factor models:
• Verifiability (by both models)
• Expandability (by both models)
• Safety (by Deutsch and Willis)
• Manageability (by Deutsch and Willis)
• Survivability (by Deutsch and Willis).
 Verifiability (suggested by Evans and Marciniak)

• Verifiability requirements define design and programming features

that enable efficient verification of the design and programming.
• Most verifiability requirements refer to modularity, to simplicity, and
to adherence to documentation and programming guidelines.
 Expandability (suggested by Evans and
Marciniak, and Deutsch and Willis)
• Expandability requirements refer to future efforts that will be needed
to serve larger populations, improve service, or add new applications
in order to improve usability.
• The majority of these requirements are covered by McCall’s flexibility
factor.
 Safety (suggested by Deutsch and Willis)
• Safety requirements are meant to eliminate conditions hazardous to
operators of equipment as a result of errors in process control
software.
Manageability (suggested by Deutsch and Willis)
• Manageability requirements refer to the administrative tools that
support software modification during the software development and
maintenance periods, such as configuration management, software
change procedures, and the like
 Survivability (suggested by Deutsch and Willis)
• Survivability requirements 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, two factors that
pertain to service continuity.