Software may be retired as

• Change in environment
• Change in infrastructure/technology
• Major change in requirement
• Increase in complexity
• Extremely difficult to maintain
• Deterioration in structure of the code
• Slow execution speed
• Poor graphical user interfaces.
 What is software reliability
• “Software reliability means operational reliability. Who
cares how many bugs are in the program? We should
be concerned with their effect on its operations” Bev
Littlewood
• As per IEEE
– “software reliability defined as the ability of a system or
component to perform its required functions under stated
conditions for a specified period of time.”
• The most accepted definition
– “It is the probability of a failure free operation of a
program for a specified time in a specified environment”
 Failures & Faults
• It is the departure of the external results of program operation
from requirements.
• Failure is something dynamic.
• Program has to be executing for a failure to occur.
• A fault is the defect in the program that, when executed under
particular conditions, causes a failure.
• There can be different set of conditions that causes failures, or
the conditions can be repeated.
• Therefore a fault can be source of more than one failure.
• A fault is a property of the program rather than a property of
its execution or behavior.
• Reliability quantities have usually been defined with respect to time.
• Execution Time – is the time that is actually spent by a processor in
executing the instruction of that program.
• Calendar time - is the familiar time that we normally experience.
• Clock Time – It represents the elapsed time from start to end of program
execution on a running computer. wait time and execution time of other
programs. Period during which the computer is shutdown are not
counted.
• If computer utilization by the program, which the fraction of time the
processor is executing the program, is constant, clock time will be
proportional to execution time.
• There are four general ways of characterizing failure
occurrences in time
– Time of failure
– Time interval between failures
– Cumulative failures experienced upto a given time
– Failures experienced in a time interval.
• All the four quantities are random variables.
• Reason
– Code is very complex and unpredictible
– The relationship between program function requested and code path
executed
 Time based failure specification
Failure number Failure time Failure interval
1 8 8
2 18 10
3 25 7
4 36 11
5 45 9
6 57 12
7 71 14
8 86 15
9 104 18
10 124 20
11 143 19
12 169 26
13 197 28
14 222 25
15 250 28
 Failure based failure specification

Time Cumulative failures Failures in interval

30 3 3
60 6 3
90 8 2
120 9 1
150 11 2
180 12 1
210 13 1
240 14 1
 Probability distribution at time ta and tb
Value of random variable Elapsed time ta=1hr Elapsed time tb=5hr
0 .10 .01
1 .18 .02
2 .22 .03
3 .16 .04
4 .11 .05
5 .08 .07
6 .05 .09
7 .04 .12
8 .03 .16
9 .02 .13
10 .01 .10
11 0 .07
12 0 .05
13 0 .03
14 0 .02
15 0 .01
Mean failures 3.04 7.77
Environment
 Uses of reliability studies
• We can use software reliability measures to evaluate
software engineering technology quantitatively.
• New techniques are continually being proposed for
improving the process of developing software, but
unfortunately they have been exposed to little
quantitative evaluation.
• Software reliability measures offer the promise of
establishing at least one criterion for evaluating the
new technology.
• Software reliability measures offer us the possibility of
evaluating development status during the test phases of a
project.
• Methods such as intuition of designers or test team ,
percent of tests completed, and successful execution of
critical functional tests have been used to evaluate testing
progress. None of these have been really satisfactory and
some have been quite unsatisfactory.
• An objective reliability measure (such as failure intensity)
established from test data provides a sound means of
determining status.
• Reliability generally increases with the
amount of testing.
• Since two of the key process attributes that a
manager must control are schedule and cost,
reliability can be intimately tied in with project
management.
• One can use software reliability measures to
monitor the operational performance of
software and to control new features added and
design changes made to the software.
• The reliability of software usually decreases as a
result of such changes.
• A reliability objective can be used to determine
when, and perhaps how large, a change will be
allowed.
• A quantitative understanding of software
quality and the various factors influencing it
and affected by it enriches into the software
product and the software development
process.
• One is then much more capable of making
informed decisions.
 Software Quality
• Everyone understand quality, appreciate
quality but may not be able to clearly express
the same.
• Different people understand different
meaning of quality like
– Conformance to requirements
– Fitness for the purpose
– Level of satisfaction
Attribute Domain Attribute

Correctness
Consistency and precision
Reliability Robustness
Simplicity
Tracebility

Accuracy
Clarity and accuracy of documentation
Usability Conformity of operational environment
Completeness
Efficiency
Testability
Attribute Domain Attribute

Accuracy and clarity of documentation

Maintainabil Modularity
ity Readability
Simplicity

Modifiability
Adaptability Expandability
Portability
 Software quality
• Quality has many characteristics and some related to
each other.
• In software the quality is commonly recognized as “lack
of bugs” in the program.
• If software has too many functional defects then, it is
not meeting its basic requirement of functionality.
• Defect rate – number of defects per million lines of
source code, per function point or any other point.
• Reliability – generally measured as number of failures
per t hours of operation.
 Software Quality Attributes
1 Reliability The extent to which a software performs its
intended functions without failure
2 Correctness The extent to which a software meets its
specification.
3 Consistency and The extent to which a software is consistent and give
precision results with precision
4 Robustness The extent to which a software tolerates the
unexpected problems
5 Simplicity The extent to which a software is simple in its
operations
6 Traceability The extent to which an error is traceable in order to
fix it
7 Usability The extent of effort required to learn, operate and
understand the functions of the software
8 Accuracy Meeting specification with precision
9 Clarity and Accuracy of The extent to which documents are clearly and
documentation accurately written
 Software Quality Attributes
10 Conformity of The extent to which a software is in conformity of
operational environment operational environment.
11 Completeness The extent to which a software is in conformity of
operational environment.
12 Efficiency The amount of computing resources and code
required by software to perform a function.
13 Testability The effort required to test a software to ensure that
it performs its intended functions.
14 Maintainability The effort required to locate and fix an error during
maintenance phase.
15 Modularity It is the extent of ease to implement, test, debug and
maintain the software.
16 Readability The extent to which a software is readable in order to
understand
17 Adaptability The extent to which a software is adaptable to new
platforms and technology
18 Modifiability The effort required to modify a software during
maintenance phase.
 Software Quality Attributes

19 Expandability The extent to which a software is expandable

without undesirable side effects.
20 Portability The effort required to transfer a program from one
platform to another platform.
 McCall Software Quality Model
• Introduced in 1977
• The model distinguishes between two level
• Higher level of quality attributes are known as
quality factors. These are external attributes
and can be measured directly.
• The second level of quality attributes is named
as quality criteria. Quality criteria can be
measured either subjectively or objectively.
• Product Operation – factor which are related to the
operation of a product are combined.
– Correctness
– Efficiency
– Integrity
– Reliability
– Usability
• These five factors are related to operational
performance, convenience, ease of usage and its
correctness.
• Product Revision – The factors which are required for
testing and maintenance are combined and are given
below
– Maintainability
– Flexibility – The effort required to modify an operational
program
– Testability
• These factors pertain to the testing and
maintainability of software. They give us idea about
ease of maintenance, flexibility and testing effort.
• Product Transition – we may have to transfer
a product from one platform to another
platform or from one technology to another
technology.
– Portability
– Reusability – The extent to which a program can
be reused in other applications.
– Interoperability – The effort required to couple
one system with another.
 Quality Criteria
• The second level of quality attributes are
quality criteria.
Boehm Software Quality Model
 Basic Execution Time Model
• The model was developed by J.D. Musa and is based on
execution time.
• It is assumed that failures may occur according to a non
homogeneous poisson process.
• Real world event may be described using processes.
– Number of telephone calls expected in a given period of time
– Expected number of road accident in a given period of time.
– Expected number of persons visiting in a shopping mall in a given
period of time.