Unit-5

Software Maintenance
Software Maintenance is the process of modifying a software product after it has been delivered
to the customer. The main purpose of software maintenance is to modify and update software
application after delivery to correct faults and to improve performance.
Need for Maintenance –
Software Maintenance must be performed in order to:
Correct faults.
Improve the design.
Implement enhancements.
Interface with other systems.
Accommodate programs so that different hardware, software, system features, and
telecommunications facilities can be used.
Migrate legacy software.
Retire software.

Categories of Software Maintenance –

Maintenance can be divided into the following:
1. Corrective maintenance:
Corrective maintenance of a software product may be essential either to rectify some bugs
observed while the system is in use, or to enhance the performance of the system.
2. Adaptive maintenance:
This includes modifications and updations when the customers need the product to run on
new platforms, on new operating systems, or when they need the product to interface with
new hardware and software.
3. Perfective maintenance:
A software product needs maintenance to support the new features that the users want or to
change different types of functionalities of the system according to the customer demands.
4. Preventive maintenance:
This type of maintenance includes modifications and updations to prevent future problems
of the software. It goals to attend problems, which are not significant at this moment but
may cause serious issues in future.

Reverse Engineering –
Reverse Engineering is processes of extracting knowledge or design information from anything
man-made and reproducing it based on extracted information. It is also called back
Engineering.
Software Reverse Engineering –
Software Reverse Engineering is the process of recovering the design and the requirements
specification of a product from an analysis of it’s code. Reverse Engineering is becoming
important, since several existing software products, lack proper documentation, are highly
unstructured, or their structure has degraded through a series of maintenance efforts.
Why Reverse Engineering?
Providing proper system documentatiuon.
Recovery of lost information.
Assisting with maintenance.
Facility of software reuse.
Discovering unexpected flaws or faults.
Uses of Software Reverse Engineering –
Software Reverse Engineering is used in software design, reverse engineering enables the
developer or programmer to add new features to the existing software with or without
knowing the source code.
Reverse engineering is also useful in software testing, it helps the testers to study the virus
and other malware code.

Cost of Maintenance
Reports suggest that the cost of maintenance is high. A study on estimating software
maintenance found that the cost of maintenance is as high as 67% of the cost of entire software
process cycle.
On an average, the cost of software maintenance is more than 50% of all SDLC phases. There
are various factors, which trigger maintenance cost go high, such as:
Real-world factors affecting Maintenance Cost
The standard age of any software is considered up to 10 to 15 years.
Older softwares, which were meant to work on slow machines with less memory and
storage capacity cannot keep themselves challenging against newly coming enhanced
softwares on modern hardware.
As technology advances, it becomes costly to maintain old software.
Most maintenance engineers are newbie and use trial and error method to rectify problem.
Often, changes made can easily hurt the original structure of the software, making it hard
for any subsequent changes.
Changes are often left undocumented which may cause more conflicts in future.

Software-end factors affecting Maintenance Cost

Structure of Software Program
Programming Language
Dependence on external environment
Staff reliability and availability
Software Reliability Issues

Hardware & Software Reliability

Hardware Reliability
Hardware reliability is the probability that the ability of the hardware to perform its function
for some period of time. It may change during certain periods such as initial burn-in or the
end of useful life.
 It is expressed as Mean Time Between Failures (MBTF).
 Hardware faults are mostly physical faults.
 Thorough testing of all components cuts down on the number of faults.
 Hardware failures are mostly due to wear and tear.
 It follows the Bathtub curve principle for testing failure.

Software Reliability
Software reliability is the probability that the software will operate failure-free for a specific
period of time in a specific environment. It is measured per some unit of time.
 Software Reliability starts with many faults in the system when first created.
 After testing and debugging enter a useful life cycle.
 Useful life includes upgrades made to the system which bring about new faults.
 The system needs to then be tested to reduce faults.
 Software reliability cannot be predicted from any physical basis, since it depends
completely on the human factors in design.
Note: There are two significant differences between hardware and software curves are:

One difference is that in the last stage, the software does not have an increasing failure rate as
hardware does. In this phase, the software is approaching obsolescence; there are no
motivations for any upgrades or changes to the software. Therefore, the failure rate will not
change.

The second difference is that in the useful-life phase, the software will experience a radical
increase in failure rate each time an upgrade is made. The failure rate levels off gradually,
partly because of the defects create and fixed after the updates.

The upgrades in above figure signify feature upgrades, not upgrades for reliability. For feature
upgrades, the complexity of software is possible to be increased, since the functionality of the
software is enhanced. Even error fixes may be a reason for more software failures if the bug
fix induces other defects into the software. For reliability upgrades, it is likely to incur a drop
in software failure rate, if the objective of the upgrade is enhancing software reliability, such
as a redesign or reimplementation of some modules using better engineering approaches, such
as clean-room method.

Hardware Reliability vs Software Reliability:

Features Hardware Reliability Software Reliability

Source of Failure Failures are caused due to defects in Failures are caused due to
design, production, and maintenance. defects in design.

Wear and Tear Failure occurs due to physical In software reliability, there is
deterioration in wear and tear. no wear and tear.
Deterioration In this prior deterioration warning In this no prior deterioration
Warning about failure. warning about failure.
Failure Curve The bathtub curve is used for failure There is no Bathtub curve for
rates apply. failure rates.
 Is Failure Time- In this failures are time-dependent. In this failures are not time-
dependent? dependent.
Reliability In this reliability can be predicted In this reliability can not be
Prediction from design. predicted from design.
Reliability The complexity of hardware The complexity of software
Complexity reliability is very high. reliability is low.
External Hardware reliability is related to External environment conditions
Environment environmental conditions. do not affect software
Impact reliability.
Reliability Reliability can’t be improved through Reliability can be improved
Improvement redundant of hardware. through redundancy of software.

Maintenance Repairs can be made that make No equivalent preventive

hardware more reliable through maintenance for software.
maintenance.

Bug vs Defect vs Error vs Fault vs Failure:

Bug
A bug refers to defects which means that the software product or the application is not
working as per the adhered requirements set. When we have any type of logical error, it
causes our code to break, which results in a bug. It is now that the Automation/ Manual Test
Engineers describe this situation as a bug.
 A bug once detected can be reproduced with the help of standard bug-reporting
templates.
 Major bugs are treated as prioritized and urgent especially when there is a risk of
user dissatisfaction.
 The most common type of bug is a crash.
 Typos are also bugs that seem tiny but are capable of creating disastrous results.
Defect
A defect refers to a situation when the application is not working as per the requirement and
the actual and expected result of the application or software are not in sync with each other.
 The defect is an issue in application coding that can affect the whole program.
 It represents the efficiency and inability of the application to meet the criteria and
prevent the software from performing the desired work.
 The defect can arise when a developer makes major or minor mistakes during the
development phase.
Error
Error is a situation that happens when the Development team or the developer fails to
understand a requirement definition and hence that misunderstanding gets translated into
buggy code. This situation is referred to as an Error and is mainly a term coined by the
developers.
 Errors are generated due to wrong logic, syntax, or loop that can impact the end-
user experience.
 It is calculated by differentiating between the expected results and the actual
results.
  It raises due to several reasons like design issues, coding issues, or system
specification issues and leads to issues in the application.
Fault
Sometimes due to certain factors such as Lack of resources or not following proper steps
Fault occurs in software which means that the logic was not incorporated to handle the errors
in the application. This is an undesirable situation, but it mainly happens due to invalid
documented steps or a lack of data definitions.
 It is an unintended behavior by an application program.
 It causes a warning in the program.
 If a fault is left untreated it may lead to failure in the working of the deployed
code.
 A minor fault in some cases may lead to high-end error.
 There are several ways to prevent faults like adopting programming techniques,
development methodologies, peer review, and code analysis.
Failure
Failure is the accumulation of several defects that ultimately lead to Software failure and
results in the loss of information in critical modules thereby making the system unresponsive.
Generally, such situations happen very rarely because before releasing a product all possible
scenarios and test cases for the code are simulated. Failure is detected by end-users once
they face a particular issue in the software.
 Failure can happen due to human errors or can also be caused intentionally in the
system by an individual.
 It is a term that comes after the production stage of the software.
 It can be identified in the application when the defective part is executed.

Some of the vital differences between bug, defect, fault, error, and failure are listed in the
below table:

Basis Bug Defect Fault Error Failure

Failure is the
A bug refers accumulation
to defects of several
A Fault is a
which means defects that
state that
that the ultimately
A Defect is a causes the An Error is a
software lead to
deviation software to mistake made in
product or Software
Definitio between the fail and the code due to
the failure and
n actual and therefore it which
application is results in the
expected does not compilation or
not working loss of
output achieve its execution fails,
as per the information
necessary
adhered in critical
function.
requirements modules
set thereby
making the
 system
unresponsive.
The defect is
identified by
The failure is
The Testers
found by the
And is
Human Developers and test engineer
Test resolved by
Raised by mistakes lead automation test during the
Engineers developers in
to fault. engineers development
the
cycle of
development
SDLC
phase of
SDLC.
Business
Defects are
Logic Faults,
classified as
Functional
follows:
and Logical
Based on Syntactic Error,
Faults,
Priority: UI screen error,
Logical bugs Graphical
High Error handling
Algorithmic User
Different Medium error, Flow
bugs Interface NA
types Low control error,
Resource (GUI) Faults,
Based on Calculation error,
bugs Performance
Severity: Hardware error
Faults,
Critical
Security
Major
Faults,
Minor
Hardware
Trivial
Faults
Wrong
design of the
data Error in code;
Receiving & definition Inability to
providing processes; compile/execute
Missing incorrect input; a program;
Logic; Environment
An Ambiguity in
Erroneous Coding/Logica variables;
Reasons irregularity code logic;
Logic; l Error leading System
behind in Logic or Misunderstandin
Redundant to the Errors;
gaps in the g of
codes breakdown of Human Error
software requirements;
software leads to the Faulty design and
non- architecture;
functioning Logical error
of the
software.
Implementin
Implementing Peer review Conduct peer Confirmation
g Test-driven
Out-of-the-box of the Test reviews and of Re-testing
development;
programming documents code-reviews; the process
Way to methods; and end to end;
Adjusting
prevent requirements Need for Carefully
enhanced
the Proper usage ; validation of bug review the
development
reasons of primary and fixes and requirements
practices and
correct Verifying the enhancing the as well as the
evaluation of
software correctness overall quality of specifications
cleanliness
coding of software the software. ;
of the code.
 practices. design and Categorizing
coding. and
evaluating the
errors and
issues.

Classification of Failures:
1. Intermittent Failures:
These failures occur sporadically and are often difficult to reproduce or diagnose. They may
not follow a predictable pattern.
Characteristics:
 May be influenced by specific, often unknown, conditions.
 Hard to trace and debug because they don't always manifest under the same
circumstances.
 Often related to timing issues, concurrency, or subtle hardware conditions.
Example: An application that crashes occasionally without any apparent pattern, potentially
due to a rare race condition.

2. Consistent Failures:
These failures occur reliably under specific conditions or inputs. They are repeatable and can
be reproduced consistently.
Characteristics:
 Easier to diagnose and fix since they occur under predictable circumstances.
 Usually tied to specific bugs in the code or flaws in logic that are triggered by certain
inputs or actions.
Example: A software application that fails every time a specific file type is uploaded, indicating
a consistent issue with handling that file format.

3. Transient Failures
These failures are temporary and may resolve themselves without any intervention. They occur
due to temporary conditions.
Characteristics:
 Typically caused by temporary environmental factors, such as network instability or
temporary resource unavailability.
 Often recoverable, with the system returning to normal operation without manual
intervention.
Example: A temporary network timeout that prevents data from being transmitted, but the
transmission succeeds upon retrying.

4. Permanent Failures:
These failures are persistent and do not resolve without intervention. They require changes to
the system to fix.
Characteristics:
 Result from definitive issues in the software that must be corrected through code
changes, configuration adjustments, or hardware replacements.
 Lead to ongoing malfunctions until addressed.
Example: A software feature that consistently causes the application to crash whenever used,
necessitating a code fix to resolve the issue.
Software Reliability Metrics

Reliability metrics are used to quantitatively expressed the reliability of the software product.
The option of which metric is to be used depends upon the type of system to which it applies
& the requirements of the application domain.

Some reliability metrics which can be used to quantify the reliability of the software product
are as follows:

1. Mean Time to Failure (MTTF)

MTTF is described as the time interval between the two successive failures. An MTTF of 200
mean that one failure can be expected each 200-time units. The time units are entirely
dependent on the system & it can even be stated in the number of transactions. MTTF is
consistent for systems with large transactions.

For example, It is suitable for computer-aided design systems where a designer will work on a
design for several hours as well as for Word-processor systems.

To measure MTTF, we can evidence the failure data for n failures. Let the failures appear at
the time instants t1,t2.....tn.

MTTF can be calculated as

2. Mean Time to Repair (MTTR)

Once failure occurs, some-time is required to fix the error. MTTR measures the average time
it takes to track the errors causing the failure and to fix them.
3. Mean Time Between Failure (MTBR)

We can merge MTTF & MTTR metrics to get the MTBF metric.

MTBF = MTTF + MTTR

Thus, an MTBF of 300 denoted that once the failure appears, the next failure is expected to
appear only after 300 hours. In this method, the time measurements are real-time & not the
execution time as in MTTF.

4. Rate of occurrence of failure (ROCOF)

It is the number of failures appearing in a unit time interval. The number of unexpected events
over a specific time of operation. ROCOF is the frequency of occurrence with which
unexpected role is likely to appear. A ROCOF of 0.02 mean that two failures are likely to
occur in each 100 operational time unit steps. It is also called the failure intensity metric.

5. Probability of Failure on Demand (POFOD)

POFOD is described as the probability that the system will fail when a service is requested. It
is the number of system deficiency given several systems inputs.

POFOD is the possibility that the system will fail when a service request is made.

A POFOD of 0.1 means that one out of ten service requests may fail.POFOD is an essential
measure for safety-critical systems. POFOD is relevant for protection systems where services
are demanded occasionally.

6. Availability (AVAIL)

Availability is the probability that the system is applicable for use at a given time. It takes into
account the repair time & the restart time for the system. An availability of 0.995 means that
in every 1000 time units, the system is feasible to be available for 995 of these. The percentage
of time that a system is applicable for use, taking into account planned and unplanned
downtime. If a system is down an average of four hours out of 100 hours of operation,
its AVAIL is 96%.

Reliability Growth Modeling

A reliability growth model is a simulation of how system dependability evolves overtime

throughout the testing process. When system failures are identified, the underlying flaws that
are generating these failures are corrected, and the system's dependability should improve
through system testing and debugging. The conceptual reliability growth model must next be
converted into a mathematical model in order to forecast dependability.
Reliability growth modeling entails comparing observed reliability at various periods in time
with known functions that demonstrate potential changes in reliability. An equal step function,
for example, implies that the dependability of a system rises linearly with each release. It is
feasible to forecast the system's dependability at some future point in time by comparing
observed reliability increase with one of these functions. As a result, reliability growth models
may be utilized to help in project planning.

The reliability growth model group measures and forecasts the improvement of reliability
programs through testing. The growth model depicts a system's dependability or failure rate as
a function of time or the number of test cases. The models in this category are listed below.

Coutinho Model

In the log-log paper, Coutinho charted the cumulative number of defects identified and the
number of corrective measures taken vs. the cumulative testing weeks. Let N(t) represent the
total number of failures and t represent the entire testing duration. The model's failure rate,
lambda (t), may be represented as,

where β0 and β1 are model parameters. This model's parameters may be estimated using the
least-squares approach.

Wall and Ferguson Model

The total number of failures at time t, m(t), may be written as,

where alpha0: and alpha1: are unidentified parameters The number of test cases or total testing
time can be used to calculate the function b(t). Similarly, at time t, the failure rate function is
given by,
Wall and Ferguson evaluated their model using a variety of software failure data and
discovered that the failure data correlated well with the model.

Advantages of Reliability Growth Models:

1. Predicting Reliability: Reliability growth models are used to predict the reliability
of a system over time, which can help organizations make informed decisions
about the allocation of resources and the prioritization of improvements to the
system.
2. Guiding the Testing Process: Reliability growth models can be used to guide the
testing process, by helping organizations determine which tests should be run, and
when they should be run, in order to maximize the improvement of the system’s
reliability.
3. Improving the Allocation of Resources: Reliability growth models can help
organizations to make informed decisions about the allocation of resources, by
providing an estimate of the expected reliability of the system over time, and by
helping to prioritize improvements to the system.
4. Identifying Problem Areas: Reliability growth models can help organizations to
identify problem areas in the system, and to focus their efforts on improving these
areas in order to improve the overall reliability of the system.

Disadvantages of Reliability Growth Models:

1. Predictive Accuracy: Reliability growth models are only predictions, and actual
results may differ from the predictions. Factors such as changes in the system,
changes in the environment, and unexpected failures can impact the accuracy of
the predictions.
2. Model Complexity: Reliability growth models can be complex, and may require
a high level of technical expertise to understand and use effectively.
3. Data Availability: Reliability growth models require data on the system’s
reliability, which may not be available or may be difficult to obtain.

*****