Module 5

Chapter -13

13.1 Introduction
we need to define the qualities required for a system. We need to judge the objectively whether
system meets the quality requirements and this needs to be measured.

13.2 The place for Software Quality in Project Planning

Quality is of concern at all stages of project planning and execution. Fig 13.1 shows the following
steps which are important.
Step 1 : Identify project scope and objectives : Some objectives related to the qualities of the
application development.
Step 2 : Identify project infrastructure : This identifies the installation standards and
procedures.
Step 3 : Analyze project characteristics: application to be implemented is examined to see if it
has any special quality requirements.
Step 4 : Identify the products and activities of the project : It is at this point of that the entry, exit
and process requirements identified for each activity.
Step 8: Review and publicize plan: At this stage the overall quality aspects of the project plan are
reviewed.

13.3 Importance of Software Quality

• Increasing criticality of software: The customer or user is anxious about the reliability of
the software. The organization relies more on their computer systems and software is used in
more safety-critical applications.
• The intangibility of software: This makes difficult to know that the tasks of the project
completed satisfactorily. It can be made tangible by demanding the developers to produce
deliverables and later they can be examined.
• Accumulating errors during software development: system development comprises of
steps and the errors from one step to another keep on accumulating in the deliverables
that are developed in later stages. So fixing errors become more expensive in the project and
debugging becomes difficult to control.
For these reasons quality management is an essential part of overall project management.

13.4 Defining Software Quality

Following details are required software quality specifications:

• Definition/description – definition of quality characteristics.

• Scale – the unit of measurement.
• Test – the practical test of the extent to which the attribute quality exists.
• Minimally acceptable – the worst value which might be acceptable, and below which the
product would have to be rejected.
• Target range – the range of values within which planned quality measurement value
should lie.
• Now – the value that applies currently.
There could be several measurements applicable to quality characteristics.

• Availability – the percentage of a particular time interval that a system is usable.

• Mean time between failures – Total service time divided by the number of failures.
• Failure on demand – the probability that a system will not be available at the time
required.
• Support activity – the number of fault reports that are generated and processed.
• Maintainability – how quickly a fault once detected, can be corrected.
• Changeability – the ease with which the software can be modified.

13.5 Software Quality Models

Galvin’s quality demission:
Defines the quality of any product in terms of eight general attributes.

• Performance – how well it performs the jobs.

• Features – how well it supports the required features.
• Reliability – probability of a product working satisfactorily within a specific period of time.
• Conformance – degree to which the product meets the requirements.
• Durability – measure of the product’s life.
• Serviceability – speed and effectiveness maintenance.
• Aesthetics – the look and feel of the product.
• Perceived quality – user’s opinion about the product quality.

McCall Model
Defines the following eleven attributes of the software.

• Correctness – the extent to which a software product satisfies its specifications.

• Reliability – the probability of the software product working satisfactorily over a given
duration.
• Efficiency – the amount of computing resources required to perform the required
function.
• Integrity – the extent to which the data of the software product remains valid.
• Usability – the effort required to operate the software product.
• Maintainability – the ease with which it is possible to locate and fix bugs in the software
product.
• Flexibility – the effort required to adapt the software product to changing requirements.
• Testability – the effort required to test the software product to ensure that it performs its
intended function.
• Portability – the effort required to transfer the software product from one hardware or
software system environment to another.
 • Reusability – the extent to which a software can be reused in other applications.
• Interoperability – the effort required to integrate the software with other software.

Dromey’s model
Dromey’s hierarchical quality model is shown in fig 13.2. The model proposes four major high-
level properties of the software: Correctness, internal characteristics, contextual
characteristics and certain descriptive properties.

Boehm’s model
The quality of a software can be defined based on three high-level characteristics. These high-
level characteristics are:

• As-is utility – how well (easily, reliably and efficiently) can it be used?
• Maintainability – how easy it is to understand, modify and then retest the software?
• Portability – how difficult would it be to make the software in a changed environment?
Fig 13.3 shows the Boehm’s hierarchical quality model based on wider range of software
attributes with greater focus on maintainability.
13.6 ISO 9126
• ISO 9126 standard was introduced in 1991 to tackle the question of the definition of
software quality.
• The documents are very lengthy and has separate documents to cater for these three
sets of needs.
• Acquirers – who are obtaining software from external suppliers.
• Developers – who are building a software product.
• Independent evaluators – who are assessing the quality of software product, not for
themselves but for a community of users.
• ISO 9126 identifies six major external quality characteristics:
• Functionality – which covers the functions that a software product provides to satisfy
user needs.
• Reliability – which relates to the capability of the software to maintain its level of
performance.
• Usability - which relates to the effort needed to use the software.
• Efficiency – which relates to the physical resources used when software is executed.
• Maintainability – which relates to effort needed to make changes to the software.
• Portability – which relates to the ability of the software to be transferred to a different
environment.
ISO 9126 also suggests sub-characteristics for each of the above primary characteristics.
Functionality:

• Interoperability – refers to the ability of the software to interact with other systems.
Reliability:

• Maturity – frequency of failure due to faults in a software product.

Usability:

• Learnability – refers to a software tool easy to learn, but it is distinguishable from

operability.
Efficiency and Maintainability:

• Analyzability – is the ease with which the cause of failure can be determined.
• Stability – refers to low risk of a modification to the software having unexpected effects.
Portability:

• Replaceability – refers to the factors that give upwards compatibility between old software
components and the new ones.
• Coexistence – refers to the ability of the software to share resources with other software
components.
Map measurements onto ratings that reflect user satisfaction:

Mappings might be as shown in table 13.1

• According to ISO9126, measurements that act as indicators of the final quality of the
software can be used at different stages of software development life cycle.

• User satisfaction can be allocated in the range, say 0-5.

• Table 13.2 shows objective measurement of some function and then relating different
measurement values to different levels of user satisfaction.
 • The scores for each quality could be given due weight by multiplying it by its importance
weighting.
• These weighted scores can then be summed to obtain an overall score for the product.
• The scores of various products are then put in the order of preference.
• For example, as shown in table 13.3 two products may be compared to usability,
efficiency and maintainability.

13.7 Product and Process Metrics

• The developers can ensure the quality of a software product based on the measurement
of attributes called product and process metrics.
• Product metrics
measures the characteristics of a product being developed such as
✓ LOC (lines of code) and
✓ function point metrics used to measure the size.
✓ PM(person-month) metric used to measure effort required to develop a
product and time required to develop a product is measured in months.
• Process metrics
✓ Measures how a development process is performing. Examples of process
metrics are review effectiveness,
✓ average number of defects found per hour of inspection,
✓ average defect correction time,
✓ productivity,
✓ average number of failures during testing per LOC.