Software Reliability

ECC 1
Software Reliability

Software Reliability is the probability of failure-free

software operation for a specified period of time in a
specified environment.
Software Reliability is also an important factor affecting
system reliability. It differs from hardware reliability in
that it reflects the design perfection, rather than
manufacturing perfection.

ECC 2
The high complexity of software is the major contributing factor of
Software Reliability problems. Software Reliability is not a function of
time.

Software Reliability is an important attribute of software quality,

together with functionality, usability, performance, serviceability,
capability, install ability, maintainability, and documentation. Software
Reliability is hard to achieve, because the complexity of software tends
to be high.

ECC 3
Source code quality

A computer has no concept of "well-written" source code. However, from a human

point of view source code can be written in a way that has an effect on the effort
needed to comprehend its behavior. Many source code programming style guides,
which often stress readability and usually language-specific conventions are aimed
at reducing the cost of source code maintenance. Some of the issues that affect
code quality include:

Readability
Ease of maintenance, testing, debugging, fixing, modification and portability
Low complexity
Low resource consumption: memory, CPU
Number of compilation or lint warnings
Robust input validation and error handling, established by software fault injection

Methods to improve the quality:

Refactoring
Code Inspection or software review
Documenting code

ECC 4
Software reliability

Software reliability is an important facet of software quality. It is defined as "the probability of failure-free
operation of a computer program in a specified environment for a specified time".
One of reliability's distinguishing characteristics is that it is objective, measurable, and can be estimated,
whereas much of software quality is subjective criteria. This distinction is especially important in the discipline
of Software Quality Assurance. These measured criteria are typically called software metrics.

The goal of reliability

The need for a means to objectively determine software quality comes from the desire to apply the techniques
of contemporary engineering fields to the development of software. That desire is a result of the common
observation, by both lay-persons and specialists, that computer software does not work the way it ought to. In
other words, software is seen to exhibit undesirable behavior, up to and including outright failure, with
consequences for the data which is processed, the machinery on which the software runs, and by extension
the people and materials which those machines might negatively affect. The more critical the application of the
software to economic and production processes, or to life-sustaining systems, the more important is the need
to assess the software's reliability.

Reliability in program development

Requirements
A program cannot be expected to work as desired if the developers of the program do not, in fact, know the
program's desired behavior in advance, or if they cannot at least determine its desired behavior in parallel with
development, in sufficient detail. What level of detail is considered sufficient is hotly debated. The idea of
perfect detail is attractive, but may be impractical, if not actually impossible, in practice. This is because the
desired behavior tends to change as the possible range of the behavior is determined through actual attempts,
or more accurately, failed attempts, to achieve it.

ECC 5
Reliability Models

Developing reliable software is one of the most difficult problems facing the software
industry. Schedule pressure, resource limitations, and unrealistic requirements can all
negatively impact software reliability. Developing reliable software is especially hard when
there is interdependence among the software modules as is the case with much of existing
software. It is also a hard problem to know whether or not the software being delivered is
reliable. After the software is shipped, its reliability is indicated by from customer feedback
- problem reports, system outages, complaints or compliments, and so forth. However, by
then it is too late; software vendors need to know whether their products are reliable before
they are shipped to customers. Software reliability models attempt to provide that
information.

There are essentially two types of software reliability models - those that attempt to predict
software reliability from design parameters and those that attempt to predict software
reliability from test data. The first type of models are usually called "defect density" models
and use code characteristics such as lines of code, nesting of loops, external references,
input/outputs, and so forth to estimate the number of defects in the software. The second
type of models are usually called "software reliability growth" models. These models
attempt to statistically correlate defect detection data with known functions such as an
exponential function. If the correlation is good, the known function can be used to predict
future behavior.

ECC 6
A software quality factor is a non-functional requirement for a software program which is not called up by the customer's
contract, but nevertheless is a desirable requirement which enhances the quality of the software program.

Understandability–clarity of purpose.
Completeness–presence of all constituent parts, with each part fully developed. All required input data must also be available.
Conciseness–minimization of excessive or redundant information or processing. This is important where memory capacity is
limited, and it is generally considered good practice to keep lines of code to a minimum. It can be improved by replacing repeated
functionality by one subroutine or function which achieves that functionality. It also applies to documents.
Portability–ability to be run well and easily on multiple computer configurations. Portability can mean both between different
hardware—such as running on a PC as well as a Smartphone—and between different operating systems—such as running on both
Mac OS X and GNU/Linux.
Consistency–uniformity in notation, symbology, appearance, and terminology within itself.
Maintainability–propensity to facilitate updates to satisfy new requirements. Thus the software product that is maintainable
should be well-documented, should not be complex, and should have spare capacity for memory, storage and processor
utilization and other resources.
Testability–disposition to support acceptance criteria and evaluation of performance. Such a characteristic must be built-in during
the design phase if the product is to be easily testable; a complex design leads to poor testability.
Usability–convenience and practicality of use. This is affected by such things as the human-computer interface. The component of
the software that has most impact on this is the user interface (UI), which for best usability is usually graphical (i.e. a GUI).
Reliability–ability to be expected to perform its intended functions satisfactorily. This implies a time factor in that a reliable
product is expected to perform correctly over a period of time. It also encompasses environmental considerations in that the
product is required to perform correctly in whatever conditions it finds itself (sometimes termed robustness).
Structuredness–organisation of constituent parts in a definite pattern. A software product written in a block-structured language
such as Pascal will satisfy this characteristic.
Efficiency–fulfillment of purpose without waste of resources, such as memory, space and processor utilization, network
bandwidth, time, etc.
Security–ability to protect data against unauthorized access and to withstand malicious or inadvertent interference with its
operations. Besides the presence of appropriate security mechanisms such as authentication, access control and encryption,
security also implies resilience in the face of malicious, intelligent and adaptive attackers.

ECC 7
Most software reliability growth models have a parameter that relates to the total
number of defects contained in a set of code. If we know this parameter and the
current number of defects discovered, we know how many defects remain in the code.
Knowing the number of residual defects helps us decide whether or not the code is
ready to ship and how much more testing is required if we decide the code is not
ready to ship. It gives us an estimate of the number of failures that our customers will
encounter when operating the software. This estimate helps us to plan the
appropriate levels of support that will be required for defect correction after the
software has shipped and determine the cost of supporting the software.

ECC 8
ECC 9
Software Reliability Growth Model Types

Software reliability growth models have been grouped into two classes of models concave and S-
shaped. These two model types are shown in Figure 2-2. The most important thing about both
models is that they have the same asymptotic behavior, i.e., the defect detection rate decreases
as the number of defects detected (and repaired) increases, and the total number of defects
detected asymptotically approaches a finite value. The theory for this asymptotic behavior is that:

(1) A finite amount of code should have a finite number of defects. Repair and new functionality
may introduce new defects, which increases the original finite number of defects. Some models
explicitly account for new defect introduction during test while others assume they are negligible
or handled by the statistical fit of the software reliability growth model to the data.

(2) It is assumed that the defect detection rate is proportional to the number of defects in the
code. Each time a defect is repaired, there are fewer total defects in the code, so the defect
detection rate decreases as the number of defects detected (and repaired) increases. The
concave model strictly follows this pattern. In the S-shaped model, it is assumed that the early
testing is not as efficient as later testing, so there is a ramp-up period during which the defect
detection rate increases. This could be a good assumption if the first QA tests are simply
repeating tests that developers have already run or if early QA tests uncover defects in other
products that prevent QA from finding
defects in the product being tested. For example, an application test may uncover as defects that
need to be corrected before the application can be run.

ECC 10
ECC 11
ECC 12
•Software Reliability Metrics
Listed below are some static code and dynamic metrics which are related to software
reliability. The static code metric is divided into three categories with measurements under
each: Line Count, Complexity and Structure, and Object-Oriented metrics. The dynamic metric
has two major measurements: Failure Rate Data and Problem Reports.
Static Code Metrics
Line Count:
Lines of Code (LOC)
Source Lines of Code (SLOC)

Complexity and Structure:

Number of Modules
Number of Go To Statements (GOTO)
Object-Oriented:
Number of Classes
Weighted Methods per Class (WMC)
Coupling Between Objects (CBO)

Dynamic Metrics
Failure Rate Data
Problem Reports

ECC 13
Defensive Programming

Defensive programming is a technique that makes programs more robust to unexpected events
such as run-time errors

Less program "crashes" at run time increases the quality of software

Unexpected events may occur due to

Erroneous user input (e.g. entering a date in the wrong format)

File input and output problems (e.g. end of file or disk full)
Problems with arithmetic (e.g. overflow)
Hardware and software interrupts (e.g. hitting the break key)
Programming language implementation of exception handling
can make defensive programming easier

An exception is a special unexpected error condition at run time

Built-in exceptions may be detected automatically by the
language implementation
Exceptions can be explicitly raised
Exceptions are handled by exception handlers to recover
from error conditions.
Exception handlers are user-defined program fragments that
are executed when an exception is raised

ECC 14
Exception Handlers

Purposes of an exception handler:

1. Recover from an exception to safely continue execution
2. If full recovery is not possible, print error message(s)
3. If the exception cannot be handled locally, clean up local
resources and re raise the exception to propagate it to another
handler
In most languages, exception handlers can be attached to a
collection of program statements
When an exception occurs in the collection of statements, a
handler is selected that matches the exception
If no handler can be found, the exception is propagated to
exception handlers of the outer scope of the statements, or if no
handler exists in the outer scope, to the caller of the subroutine

ECC 15