SOFTWARE QUALITY

Introduction
Software quality – IEEE definition
Software quality is:
1. The degree to which a system, component, or process meets specified requirements.
2. The degree to which a system, component, or process meets customer or user needs or
expectations.
Software quality – Pressman’s definition
Software quality is defined as: Conformance to explicitly stated functional and performance
requirements, explicitly documented development standards, and implicit characteristics that are
expected of all professionally developed software.
 Software quality assurance
The IEEE definition Software quality assurance is:
1. A planned and systematic pattern of all actions necessary to provide
adequate confidence that an item or product conforms to
established technical requirements.
2. A set of activities designed to evaluate the process by which the
products are developed or manufactured. Contrast with quality
control.
 Software Quality Challenges
The uniqueness of software quality assurance
1. High complexity, as compared to other industrial products
2. Invisibility of the product
3. Opportunities to detect defects (“bugs”) are limited to the
product development phase
The environments for which SQA methods are developed
1. Contract conditions and commitments defining the contents
and timetable.
2. The conditions of the customer–supplier relationship, as
realized by the need for consultation with the customer and the
acquisition of his approval.
3. Teamwork requirements.
4. Need for cooperation and coordination with other software and
hardware development teams both internally and externally.
5. Need for interfaces with other software systems.
6. Need to continue carrying out a project when team members
change.
7. Need to conduct maintenance of the software system for
several years
 Objectives
Software development (process-oriented): Software maintenance (product-oriented):
1. Assuring an acceptable level of confidence that the 1. Assuring with an acceptable level of confidence
software will conform to functional technical that the software maintenance activities will
requirements. conform to the functional technical requirements.
2. Assuring an acceptable level of confidence that the 2. Assuring with an acceptable level of confidence
software will conform to managerial scheduling that the software maintenance activities will
conform to managerial scheduling and budgetary
and budgetary requirements. requirements.
3. Initiating and managing of activities for the 3. Initiating and managing activities to improve and
improvement and greater efficiency of software increase the efficiency of software maintenance
development and SQA activities. This means and SQA activities. This involves improving the
improving the prospects that the functional and prospects of achieving functional and managerial
managerial requirements will be achieved while requirements while reducing costs.
reducing the costs of carrying out the software
development and SQA activities
 Causes of software errors
1. Faulty requirements definition
2. Client–developer communication failures
3. Deliberate deviations from software requirements
4. Logical design errors
5. Coding errors
6. Non-compliance with documentation and coding instructions
7. Shortcomings of the testing process
8. Procedure errors
9. Documentation errors
Software quality factors
The need for comprehensive software quality requirements
There is a need for a comprehensive definition of requirements that will cover all attributes of
software and aspects of the use of software, including usability aspects, reusability aspects,
maintainability aspects, and so forth in order to assure the full satisfaction of the users.

The great variety of issues related to the various attributes of software and its use and
maintenance, as defined in software requirements documents, can be classified into content groups
called quality factors
• The team responsible for defining the software requirements of a software system to examine the
need to define the requirements that belong to each factor
• Software requirement documents are expected to differ in the emphasis placed on the various
factors, a reflection of the differences to be found among software projects
• Not all the factors will be universally “represented” in all the requirements documents.
 Software quality factors
Classifications of software requirements
into software quality factors
The classic model of software quality factors,
suggested by McCall, consists of 11 factors.
McCall’s factor model
McCall’s factor model classifies all software
requirements into 11 software quality
factors. 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

Fig: McCall’s factor model tree

 Software quality factors -Product operation software quality factor

Correctness
Correctness requirements are defined in a list of the software system’s required outputs, such as a query
display of a customer’s balance in the sales accounting information system, or the air supply as a function
of temperature specified by the firmware of an industrial control unit. Output specifications are usually
multidimensional; some common dimensions include:
• The output mission (e.g., sales invoice printout, and red alarms when temperature rises above 250°F)
• The required accuracy of those outputs that can be adversely affected by inaccurate data or inaccurate calculations.
• The completeness of the output information, which can be adversely affected by incomplete data.
• The up-to-dateness of the information (defined as the time between the event and its consideration by the software
system).
• The availability of the information (the reaction time, defined as the time needed to obtain the requested
information or as the requested reaction time of the firmware installed in a computerized apparatus).
• The standards for coding and documenting the software system.
 Software quality factors -Product operation software quality factor
Reliability
Reliability requirements deal with failures to provide service. They determine the maximum allowed software system failure
rate, and can refer to the entire system or to one or more of its separate functions.
Efficiency
Efficiency requirements deal with the hardware resources needed to perform all the functions of the software system in
conformance to all other requirements. The main hardware resources to be considered are the computer’s processing
capabilities (measured in MIPS – million instructions per second, MHz or megahertz – million cycles per second, etc.), its data
storage capability in terms of memory and disk capacity (measured in MBs – megabytes, GBs – gigabytes, TBs – terabytes, etc.)
and the data communication capability of the communication lines (usually measured in KBPS – kilobits per second, MBPS –
megabits per second, and GBPS – gigabits per second). The requirements may include the maximum values at which the
hardware resources will be applied in the developed software system or the firmware. Another type of efficiency requirement
deals with the time between recharging of the system’s portable units, such as, information systems units located in portable
computers, or meteorological units placed outdoors.
Integrity
Integrity requirements deal with the software system security, that is, requirements to prevent access to unauthorized persons,
to distinguish between the majority of personnel allowed to see the information (“read permit”) and a 403 Software quality
factors limited group who will be allowed to add and change data (“write permit”), and so forth.
Usability
Usability requirements deal with the scope of staff resources needed to train a new employee and to operate the software
system.
 Software quality factors -Product revision software quality factors
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. This
factor’s requirements refer to the modular structure of software, the internal program documentation, and the
programmer’s manual, among other items.
Flexibility
The capabilities and efforts required to support adaptive maintenance activities are covered by the flexibility
requirements. These include the resources (i.e. 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, 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 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. 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. Another
type of these requirements deals with automatic diagnostic checks applied by the maintenance technicians to detect
the causes of software failures.
 Software quality factors - Product transition software quality factors
Portability
Portability requirements tend to the adaptation of a software system to other environments consisting of different
hardware, different operating systems, and so forth. These requirements make it possible to continue using the same
basic software in diverse situations or to use it simultaneously in diverse hardware and operating systems situations.
Reusability
Reusability requirements deal with the use of software modules originally designed for one project in a new software
project currently being developed. They may also enable future projects to make use of a given module or a group of
modules of the currently developed software. The reuse of software is expected to save development resources,
shorten the development period, and provide higher quality modules. These benefits of higher quality are based on
the assumption that most of the software faults have already been detected by the quality assurance activities
performed on the original software, by users of the original software, and during its earlier reuses.
Interoperability
Interoperability requirements focus on creating interfaces with other software systems or with other equipment
firmware (for example, the firmware of the production machinery and testing equipment interfaces with the
production control software). Interoperability requirements can specify the name(s) of the software or firmware for
which interface is required. They can also specify the output structure accepted as standard in a specific industry or
applications area.
 Alternative models of software quality factors

• The Evans and Marciniak

factor model (Evans and
Marciniak, 1987)
• The Deutsch and Willis
factor model (Deutsch
and Willis, 1988)
 Alternative models of software quality factors
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. These errors can result in inappropriate reactions to dangerous situations or to the failure to provide alarm
signals when the dangerous conditions to be detected by the software arise.
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. Although these
requirements may refer separately to total and to partial failures of services, they are especially geared to failures of essential
functions or services. Significant similarity exists between the survivability factor and the reliability factor described in McCall’s
model.