UNIT-II

SOFTWARE QUALITY
 BACKGROUND

There are four variables that need to be controlled in the software

development process XP – cost, time, scope and quality. Further
there is an axiom that states that external forces can set at most
three of these variables with the remainder being set by the
development team.

Time, cost and scope can all operate within acceptable ranges, but
quality is a terrible control variable as it only allows very short
term gains at a very high cost to all parties involved.
 WHAT IS QUALITY

Five different perspectives:

The transcendental perspective defines quality as something

that can be recognized but not defined in advance.
The user perspective defines quality as fit for purpose.
The manufacturing perspective defines quality as
conformance to specification.
The product view defines quality in terms of essential
characteristics of the product in question.
The value-based view defines quality in terms of the amount a
customer is willing to pay for it.
 WHAT IS QUALITY

“A high quality product is one which has associated with

it a number of quality factors. These could be
described in the requirements specification; they could
be cultured, in that they are normally associated with
the artifact through familiarity of use and through the
shared experience of users; or they could be quality
factors which the developer regards as important but
are not considered by the customer and hence not
included in the requirements specification"
 WHAT IS QUALITY

Fitzpatrick:
Software quality is the extent to which an
industry-defined set of desirable features are
incorporated into a product so as to enhance
its lifetime performance.
 MEASURING QUALITY

The perspective we take on quality influences how we define it. But

we also want to be able to measure quality so we can establish
baselines, predict likely quality and monitor improvement.

Users assess software product quality in terms of their interaction

with the final product. Product attributes that contribute to user
satisfaction are a mixture of .

 The product’s functions, which are either present or absent;

 The product’s nonfunctional qualities, which is measurable within
some range; and
 The constraints that determine if a customer will use a particular
product.
 MEASURING QUALITY – user’s
view
When users think of software quality, they often think of software
quality, they often think of reliability.

Users, however, often measure more than reliability. They are also
concerned about usability, including ease of installation, learning
and use.
 MEASURING QUALITY –
manufacturer’s view
Manufacturer’s vies of quality suggests two characteristics to measure:

Defect counts: Defects counts are the number of known defects

recorded against a product during development and use. For more
detailed analysis, we can categorize defects on the basis of the phase or
activity where the defect was introduced, as well as the phase or
activity in which it was detected. This information can be especially
helpful in evaluating the effects of process change.

Rework Costs: Defects differ in their effect on the system: some take a
little time to find and fix; others are catastrophic and consume valuable
resources. To monitor the effect of defect detection and correction, we
often measure rework costs-
 QUALITY MODEL

A quality model is the set of characteristics and

the relationships between them, which
provide the basis for specifying quality
requirements, and evaluating quality.
McCall’s Quality Model
 McCall’s Quality Model
McCall started with a volume of 55 quality characteristics
which have an important influence on quality, and called them
"factors". For reasons of simplicity, McCall then reduced the
number of characteristics to the following eleven:

External quality integrity Internal quality efficiency

Integrity Efficiency
Reliability Maintainability
Usability Testability
Accuracy Flexibility
Interface Facility
Re-usability
Transferability
 McCall’s Quality Model
Efficiency: McCall's view of efficiency or performance is concerned with the efficient
use of computer code to perform processes and the efficient use of storage resources.
There are a number of techniques that can be used to achieve both of these objectives.
Typical of these are:
Programming languages. Selecting the most appropriate programming language for
the problem has a major impact on program efficiency.
Operating systems. Modern operating systems have the ability to perform multi-
tasking thereby improving system performance by facilitating background operations.
Design. Strategies that address cohesion and coupling, normalization techniques to
reduce data redundancy and algorithms that optimize process time should always be
employed.
Access strategies. Algorithms that optimize seek time, rotational delay and data
transfer time must be continuously searched out and implemented to improve
efficiency.
Programming techniques. Typical good programming techniques and practice like:
 McCall’s Quality Model
Integrity: The extent to which illegal access to the programs and data of a product can
be controlled. McCall et al.
Integrity has to concern itself with controls for preventing inaccurate data entering the
system and detecting it if it does. It also has to concern itself with preventing changes
to the software which compromise its original purpose.
French (1986) states that the aims of these controls are:

a. To ensure that all data are processed

b. To preserve the integrity of maintained data
c. To detect, correct and re-process all errors
d. To prevent and detect fraud".

He also suggests that there are five different types of control. Manual checks which
are applied to documents before computer processing, data preparation controls,
validation checks, batch controls and file controls. Only the last three of these can be
built into the software to ensure integrity.
 McCall’s Quality Model
Reliability: The extent to which a program can be maintained so that it can fulfill its
specific function.

The mean time between failures - under pre-defined conditions, the average time
between consecutive failures over a given period in the life of a system.

The mean time to repair - the average time to repair or maintain equipment.

The mean time to recover - the average time to return a system to operation after a
failure. The time involved should include periods taken to re-instate from previous
checkpoints.

The probability of failure - the use of formal methods to predict the likelihood that a
system will behave in an expected way under certain circumstances. Probability of
failure is most appropriate to safety-critical systems and "continuous running" systems.
 McCall’s Quality Model
Usability: The cost/effort to learn and handle a product.

General ergonomics is concerned with equipment and the work environment.

Equipment is concerned with the selection of display screens, keyboards, work surfaces
and work chair. The environment like space requirements, lighting and distracting
reflections should all be such that the user is as comfortable as possible. Noise, heat
radiation and humidity are also considered as part of the desired environment.

Software ergonomics is concerned with topics like how suitable is the software for the
intended operations. How easy is it for users to learn and to master it.
 McCall’s Quality Model

Accuracy: The extent to which a program fulfils its specification.

Ghezzi et al. also prefer the term correctness and their definition is "A
program is functionally correct if it behaves according to the specifications of the
functions it should provide".
 McCall’s Quality Model
Maintainability: The cost of localizing and correcting errors.
Ghezzi et al. (1991) divide maintenance into three categories: corrective, adaptive and
perfective and only corrective is concerned with correcting errors as suggested by
McCall.
Corrective maintenance is concerned with removing minor bugs left after development
and testing are completed. This process is also involved after other maintenance
activities.

Adaptive maintenance is concerned with changing the software to reflect changes in

the user‘s requirements. For example changes in VAT rates, income tax bands or
income tax rates. Or, a user might wish to add more functionality.

Perfective maintenance seeks to improve the algorithms used in the software to

enhance performance. Perfective maintenance is often influenced by technological
developments.
 McCall’s Quality Model
Testability: The cost of program testing for the purpose of safeguarding that the
specific requirements are met.
Sommerville (1992) suggest five stages - unit testing, module testing, subsystem
testing, system testing and acceptance testing. In ISO 9000-3 names them as - item
testing, integration testing, system testing and acceptance testing.
Item testing - Standalone components are individually tested to ensure that they
function properly. A substantial amount of item or unit testing is completed by
programmers as part of their normal role.
Integration testing - Brings together standalone components into modules which are
tested to reflect how they link in a new environment. Integration testing is also referred
to as module testing.
System testing - Best performed as a full test run of the system that the client is about
to receive but done without the client being present. It is the supplier's opportunity to
confirm that the requirements specification has been fully achieved.
Acceptance testing - The client running the new system to ensure that it complies with
the original specifications. Acceptance testing is often referred to as Alpha testing.
 McCall’s Quality Model
Flexibility: The cost of product modification

Recent interpretation of flexibility would be more associated with adaptability, ie. being
able to change or reconfigure the user interface to suit users' preferences. This is a
usability quality issue and is better considered in the usability section.

Interface facility (Interoperability): The cost of connecting two products with one
another.
This is the development strategy that encourages product development in a
manner that it can interact with other products.
 McCall’s Quality Model
Re-usability: The cost of transferring a module or program to another application.

Re-usability addresses the concept of writing code so that it can be used more than
once.

Transferability: The cost of transferring a product from its hardware or operational

environment to another.

The modern expression for this quality factor is portability. Portability is the strategy
of writing software to run on one operating system or hardware configuration while
being conscious of how it might be refined with minimum effort to run on other
operating systems and hardware platforms as well.

Sommerville (1992) considers portability as a special case of software re-use "where

the whole application system is re-used by implementing it across a range of different
computers and operating systems.
THE BOEHM MODEL (1978)

The Boehm’s quality model address three main

Questions(high level) that a buyer of software has:

• As-is utility: How well (easily, reliably,

efficiently) can I use it as-is?
• Maintainability: How easy is it to understand,
modify and retest?
• Portability: Can I still use it if I change my
environment?
 THE BOEHM MODEL (1978)
The intermediate level characteristic represents Boehm’s 7 quality factors that
together represent the qualities expected from a software system:

Portability (General utility characteristics): Code possesses the characteristic

portability to the extent that it can be operated easily and well on computer
configurations other than its current one.

Reliability (As-is utility characteristics): Code possesses the characteristic

reliability to the extent that it can be expected to perform its intended functions
satisfactorily.

Efficiency (As-is utility characteristics): Code possesses the characteristic

efficiency to the extent that it fulfills its purpose without waste of resources.

Usability (As-is utility characteristics, Human Engineering): Code possesses the

characteristic usability to the extent that it is reliable, efficient and human-engineered.
 THE BOEHM MODEL (1978)
Testability (Maintainability characteristics): Code possesses the characteristic
testability to the extent that it facilitates the establishment of verification criteria
and supports evaluation of its performance.

Understandability (Maintainability characteristics): Code possesses the

characteristic understandability to the extent that its purpose is clear to the
inspector.

• Flexibility (Maintainability characteristics, Modifiability): Code possesses the

characteristic modifiability to the extent that it facilitates the incorporation of
changes, once the nature of the desired change has been determined.
(Note the higher level of abstractness of this characteristic as compared with
augmentability).
THE BOEHM MODEL (1978)
FURPS
 FURPS
Functionality :
The F in the FURPS acronym represents all the system-wide functional requirements
that we would expect to see described.

The functional requirements can also be very technically oriented. Functional

requirements that you may consider to be also architecturally significant system-wide
functional requirements may include auditing, licensing, localization, mail, online help,
printing, reporting, security, system management, or workflow. Each of these may
represent functionality of the system being developed and they are each a system-wide
functional requirement.

Usability:
Usability includes looking at, capturing, and stating requirements based around user
interface issues, things such as accessibility, interface aesthetics, and consistency within
the user interface.
 FURPS
Reliability:
Reliability includes aspects such as availability, accuracy, and recoverability, for
example, computations, or recoverability of the system from shut-down failure.

Performance:
Performance involves things such as throughput of information through the system,
system response time (which also relates to usability), recovery time, and startup time.

Supportability :
Finally, we tend to include a section called Supportability, where we specify a number
of other requirements such as testability, adaptability, maintainability, compatibility,
configurability, installability, scalability, localizability, and so on
 SOFTWARE PROJECT PLANNING

Project Planning is an aspect of Project Management that focuses a lot on Project

Integration. The project plan reflects the current status of all project activities and is used
to monitor and control the project.

The Project Planning tasks ensure that various elements of the Project are coordinated and
therefore guide the project execution.

Project Planning helps in

Facilitating
communication
Monitoring/measuring the project progress, and
Provides overall documentation of assumptions/planning decisions
 SOFTWARE PROJECT PLANNING
Factor Elaboration Focus
People Users, developers, stakeholders, vendors and Environment, communication,
partners. productivity, skills, motivation, and
team management.
Product Deliverables, scope, form and format, Cost, feasibility, quality and risk.
objectives, key functions and objectives
Process The method through which product will be Plan of SP development catering for
delivered - process models, choice of SPM framework made of common
technology, processes of development. umbrella activities like scope
definition, analysis, estimation,
feasibility, risk management, and
quality assurance.
Project Definition, scope, business goal, economics, Key deliverables, cost control, time
resource, budgets, configuration, clear start management, meeting deadlines and
and closure. fulfilling commitments to customer
satisfaction.
 SOFTWARE PROJECT
PLANNING – the process
Project Planning spans across the various aspects of the Project.
Generally Project Planning is considered to be a process of estimating,
scheduling and assigning the projects resources in order to deliver an
end product of suitable quality.

Typically Project Planning can include the following types of project

Planning:
 Project scope
1)Project Scope Definition and Scope Planning
2)Quality Planning
3)Project Activity Definition and Activity Sequencing
4)Time, Effort and Resource Estimation
5)Risk Factors Identification
6)Schedule Development
7)Cost Estimation and Budgeting
8)Organizational and Resource Planning
9)Risk Management Planning
10)Project Plan Development and Execution
11)Performance Reporting
12)Planning Change Management
13)Project Rollout Planning
 Project Scope Definition and Scope
Planning

In this step documentation of the project work is done

that would help us achieve the project goal. In this
phase documentation of assumptions, constraints,
user expectations, Business Requirements,
Technical requirements, project deliverables, project
objectives and everything that defines the final
product requirements is done. This is the foundation
for a successful project completion.
 Quality Planning

The relevant quality standards are determined for the

project. This is an important aspect of Project
Planning. Based on the inputs captured in the
previous steps such as the Project Scope,
Requirements, deliverables, etc. various factors
influencing the quality of the final product are
determined. The processes required to deliver the
Product as promised and as per the standards are
defined.
Project Activity Definition and Activity
Sequencing

In this step we define all the specific activities that

must be performed to deliver the product by
producing the various product deliverables. The
Project Activity sequencing identifies the
interdependence of all the activities defined.
 Time, Effort and Resource Estimation:

Once the Scope, Activities and Activity

interdependence is clearly defined and documented,
the next crucial step is to determine the effort required
to complete each of the activities. The Effort can be
calculated using one of the many techniques available
such as Function Points, Lines of Code, Complexity of
Code, Benchmarks, etc.
Risk Factors Identification:

“Expecting the unexpected and facing it”

It is important to identify and document the risk
factors associated with the project based on the
assumptions, constraints, user expectations,
specific circumstances, etc.
 Schedule Development:

The time schedule for the project can be arrived at

based on the activities, interdependence and
effort required for each of them. The schedule
may influence the cost estimates, the cost benefit
analysis and so on.
Again various factors may impact in successfully
scheduling a project
...........o Teams not directly under our control
...........o Resources with not enough experience
 Cost Estimation and Budgeting:

Based on the information collected in all the

previous steps it is possible to estimate the cost
involved in executing and implementing the project.
See the article on "Software Cost Estimation" for
more details. A Cost Benefit Analysis can be arrived
at for the project. Based on the Cost Estimates
Budget allocation is done for the project.
 Organizational and Resource Planning

Based on the activities identified, schedule and budget

allocation resource types and resources are
identified. One of the primary goals of Resource
planning is to ensure that the project is run
efficiently. This can only be achieved by keeping all
the project resources fully utilized as possible. The
success depends on the accuracy in predicting the
resource demands that will be placed on the project.
There are various types of resources – Equipment,
Personnel, Facilities, Money, etc
Risk Management Planning

Risk Management is a process of identifying,

analyzing and responding to a risk. Based on the
Risk factors Identified a Risk resolution Plan is
created. The plan analyses each of the risk factors
and their impact on the project. The possible
responses for each of them can be planned.
Throughout the lifetime of the project these risk
factors are monitored and acted upon as necessary.
 Project Plan Development and
Execution

Project Plan Development uses the inputs gathered

from all the other planning processes such as Scope
definition, Activity identification, Activity
sequencing, Quality Management Planning, etc. A
detailed Work Break down structure comprising of
all the activities identified is used. The tasks are
scheduled based on the inputs captured in the steps
previously described. The Project Plan documents
all the assumptions, activities, schedule, timelines
and drives the project.
Performance Reporting

The progress is compared with the schedule and

timelines documented in the Project Plan. Various
techniques are used to measure and report the
project performance such as EVM (Earned Value
Management ) A wide variety of tools can be
used to report the performance of the project such
as PERT Charts, GANTT charts, Logical Bar
Charts, Histograms, Pie Charts, etc.

NEXT
Planning Change Management:
Analysis of project performance can necessitate
that certain aspects of the project be changed. The
Requests for Changes need to be analyzed
carefully and its impact on the project should be
studied. Considering all these aspects the Project
Plan may be modified to accommodate this
request for Change.
Project Rollout Planning
Whenever a Project is rolled out it may affect the
technical systems, business systems and
sometimes even the way business is run. For an
application to be successfully implemented not
only the technical environment should be ready
but the users should accept it and use it
effectively. For this to happen the users may need
to be trained on the new system. All this requires
planning.
 PERT CHART

A PERT chart is a graphic representation of a project’s schedule, showing

the sequence of tasks, which tasks can be performed simultaneously, and
the critical path of tasks that must be completed on time in order for the
project to meet its completion deadline.

The chart can be constructed with a variety of attributes, such as earliest

and latest start dates for each task, earliest and latest finish dates for each
task, and slack time between tasks.

A PERT chart can document an entire project or a key phase of a project.

The chart allows a team to avoid unrealistic timetables and schedule
expectations, to help identify and shorten tasks that are bottlenecks, and
to focus attention on most critical tasks.