SOFTWARE ENGINEERING TECHNIQUES
LESSON 18:
Topics Covered
Calendar time to execution time relationship, Parametric model,
Software Maintenance, Categories of software maintenance,
Problems during software maintenance, Potential solutions to
maintenance problems
Objectives
Upon completion of this Lesson, you should be able to:
• Know what is the relationship between calendar time and
execution time
• Know what is Parametric model and software maintenance
• Know what are the problems during software maintenance
Calendar Time to Execution Time Relationship
Resource quantities and utilizations are assumed to be constant
for the period over which the model is being applied. This is a
reasonable assumption, as increases are usually not feasible.
The instantaneous ratio of calendar time to execution time can
be obtained by dividing the resource usage rate of the limiting
resource by the constant quantity of resources available that can
be utilized. Let t be calendar time. Then
dt /dt = (1/ Pr ?r) dxr/dt 6.15
The quantity Pr represents resource available. Note that Pr is the
utilization. The above ratio must be computed separately for
each resource limited period. Since xr is a function of t , we now
have a relationship between t and in each resource-limited
period.
The form of the instantaneous calendar time to execution time
ratio for any given limiting resource and either model is shown
in figures.
The shape of this curve will parallel that of the failure intensity.
The curve approaches an asymptote of (S/PrPr Note that the
asymptote is 0 for the failure correction personnel resource. At
any given time, the maximum of the ratios for the three
limiting resources actually determines the rate at which calendar
time is expended; this is illustrated in figure 6.12. The maxi-
mum is plotted as a solid curve. When the curve for a resource
© Copy Right: Rai University
66
is not maximum (not limiting), it is plotted thin. Note the
transaction points FI and IC.
Here, the calendar time to execution time ratios of two
resources are equal and the limiting resource changes. The point
FC is a potential but not true transition point. Neither resource
F nor resource C is limiting near this point. The calendar time
component allows you to estimate the calendar time in days
required to meet the failure intensity objective. The value of this
interval is particularly useful to software managers and engi-
neers. One may determine it from the additional execution time
and additional number of failures needed to meet the objective
that we found for the execution time component. Second, one
now determines the date on which the failure intensity objective
will be achieved. This is a simple variant of the first quantity
that takes account of things like weekends and holidays.
However, it is useful quantity because it speaks in terms
managers and engineers understand.
Reliability Allocation
Most software reliability models are used for reliability estima-
tion. Almost all the existing models estimate the reliability in
the testing and operational stages, after the completion of the
initial stage of product development. These models answer the
question, “how reliable is the system?” These models rely on
the data generated after the initial stage of development and
coding, hence they could hardly have any impact on the
planning and design stages of a software project. They provide
no guidelines for how much time and effort should be spent
on different modules of the software in the planning, design,
and early coding and development stages; the stages, which are
crucial to subsequent reliability of the system. Once the damage
is done, errors are committed; these models step in to measure
the extent of injury and may at most recommend the necessary
dosage of corrective action. In this section, we discuss software
reliability apportionment schemes, which attempt to answer the
question, “how reliable should each system module be?” These
provide the reliability guidelines well in advance of any develop-
ment at the planning and design stage of the system, hence
designing reliability into the system and making it a cost
3E.253
effective control tool for development management. Reliability
allocation deals with setting of reliability goals for individual
modules such that a specified system reliability goal is met and
the modules’ goals are “well balanced” among themselves. Well
balanced usually refers to approximate equality of development
time, difficulty, or risk or to the minimization of overall
development cost. Reliability requirements determined through
systematic allocation procedure would be more realistic,
consistent and economically attainable than those obtained
through subjective or haphazard methods, or those resulting
from crash programs initiated after unfortunate field experience.
Two such systematic approaches are discussed below.
Parametric Model
The problem of reliability allocation is to apportion the
reliability goal R to n modules such that
n corrections, enhancements of capabilities, deletion of obsolete
? R i* >= R ——(1)
I=1
where,R: System reliability goal
Ri*: Allocated reliability for module i
After the development of any software, it is not expected to be
modified at the user end till there is a crash or till the next
version is to be released. For this situation, the failure rate of
every module and hence of the whole system can be assumed
constant. Then if, ?i* is the allocated failure rate for module i
and ? is the required failure rate for the system, equation (1) is
equivalent to
n More than two-fifths of maintenance activities are extensions
∑ ? i* <= ? ——(2)
I=1
As ?i* is obviously a fraction of the total failure rate, let
?i* = W i ? ——(3)
where Wi is the weight age factor for module i. These weight
age factors have obviously to be defined in such a manner so as
to have
n and conclusions, incorrect implementation of design specifica-
∑ Wi=1 ——( 4)
i=l
Also Ri* can be expressed as
Ri* = ( R)wi
To make sure that equation (4) is satisfied, we define Wi in
terms of proportionality factors Zi’s as
Software Maintenance
Software maintenance is a task that every development group
has to face when the software is delivered to the customer’s site,
© Copy Right: Rai University
3E.253
installed and is operational. Therefore, delivery or release of
SOFTWARE ENGINEERING TECHNIQUES
software inaugurates the maintenance phase of the life cycle.
The time spent and effort required keeping software operational
after release is very significant and consumes about 40-70% of
the cost of the entire life cycle. Despite the fact that it is very
important and challenging task; it is routinely the poorly
managed headache that nobody wants to do.
What is Software Maintenance?
The term maintenance is a little strange when applied to
software. In common speech, it means fixing things that break
or wear out. In software, nothing wears out; it is either wrong
from the beginning, or we decide later that we want to do
something different. However, the term is so common that we
must live with it .
Software Maintenance is a very broad activity that includes error
capabilities, and optimization. Because change is inevitable,
mechanisms must be developed for evaluating, controlling and
making modifications. So any work done to change the
software after it is in operation is considered to be maintenance.
The purpose is to preserve the value of software over time. The
value can be enhanced by expanding the customer base, meeting
additional requirements, becoming easier to use, more efficient
and employing newer technology. Maintenance may span for
500 years, whereas development may be 1-2 years.
Categories of Maintenance
The only thing that remains constant in life is “CHANGE”. As
the specification of the computer systems change, reflecting
changes in the external world, so must the system themselves.
and modifications requested by the users.
There are four major categories of software maintenance, which
are discussed below:
Corrective Maintenance
This refers to modifications initiated by defects in the software.
A defect can result from design errors, logic errors and coding
errors. Design errors occur when, changes made to the software
are incorrect, incomplete, wrongly communicated or the change
request is misunderstood. Logic errors result from invalid tests
tions, faulty logic flow or incomplete test data. Coding errors are
caused by incorrect implementation of detailed logic design and
incorrect use of the source code logic. Defects are also caused by
data processing errors and system performance errors.
In the event of system failure due to an error, actions are taken
to restore operation of the software system. Due to pressure
from management, maintenance personnel sometimes resort to
emergency fixes known as “patching”. The adhoc nature of this
approach often gives rise to a range of problems that include
increased program complexity and unforeseen ripple effects.
Unforeseen ripple effects imply that a change to one part of a
program may affect other sections is an unpredictable manner,
thereby leading to distortion in the logic of the system. This is
often due to lack of time to carry out a through “impact
analysis” before effecting the change.
67
 Adaptive Maintenance
SOFTWARE ENGINEERING TECHNIQUES
It includes modifying the software to match changes in the ever-
changing environment. The term environment in this context
refers to the totality of all conditions and influences which act
from outside upon the software, for example, business rules,
government policies, work patterns, software and hardware
operating platforms. A change to the whole or part of this
environment will require a corresponding modification of the
software.
Thus, this type of maintenance includes any work initiated as a
consequence of moving the software to a different hardware or
software platform-compiler, operating system or new processor.
Any change in the government policy can have far-reaching
ramifications on the software.
When European countries had decided to go for “single
European currency”, this change affected all banking system
software and was modified accordingly
Perfective Maintenance
It means improving processing efficiency or performance, or
restructuring the software to improve changeability. When the
software becomes useful, the user tends to experiment with
new cases beyond the scope for which it was initially developed.
Expansion in requirements can take the form of enhancement
of existing system functionality or improvement in computa-
tional efficiency; for example, providing a Management
Information System with a data entry Module or a new message
handling facility.
Other Types of Maintenance
There are long term effects of corrective, adaptive and perfective
changes. This leads to increase in the complexity of the
software, which reflects deteriorating structure. The work is
required to be done to maintain it or to reduce it, if possible.
This work may be named as preventive maintenance. This term
is often used with hardware systems and implies such things as
lubrication of parts before need occurs, or automatic replace-
ment of banks of light bulbs before they start to individually
burn out. Since software does not degrade in the same way as
hardware and does not need maintenance to retain the presently
established level of functionality. Some authors do not use this
term. That is why we have included this type of activity under
“Other Types of Maintenance” category. This activity is usually
initiated from within the maintenance organization with the
intention of making program easier to understand and hence
facilitating future maintenance work. This includes code
restructuring, code optimization and documentation updating.
After a series of quick fixes to software, the complexity of its
source code can increase to an unmanageable level, thus
justifying complete restructuring of the code. Code optimiza-
tion can be performed to enable the programs to run faster or
to make more efficient use of storage. Updating user & system
documentation, though frequently ignored, is often necessary
when any part of software is changed. The documents affected
by the change should be modified to reflect the current state of
the system.
© Copy Right: Rai University
68
Problems During Maintenance
The most important problem during maintenance is that
before correcting or modifying a program, the programmer
must first understand it. Then, the programmer must under-
stand the impact of the intended change. Few problems are
discussed below [LEHM85, ARN082]:
• Often the program is written by another person or group
of persons working over the years in isolation from each
other.
• Often the program is changed by person who did not
understand it clearly, resulting in a deterioration of the
program’s original organization.
• Program listings, even those that are well organized, are
not structured to support reading for comprehension. We
normally read an article or book straight through, but with
listing, programmer rummages back and forth.
• There is a high staff turnover within Information
Technology industry. Due to this many systems are
maintained by persons who are not the original authors.
These persons may not have adequate knowledge about
the system. This may mean that these persons may
introduce changes to programs without being aware of
their effects on other parts of the system - the ripple, effect.
This problem may be worsened by the absence of
documentation. Even where it exists, it may be out of date
or inadequate.
• Some problems only become clearer when a system is
incuse.
Many users know what they want but lack the ability to
express it in a form understandable to programmers/
analysts. This is primarily due to information gap.
• Systems are not designed for change. If there is
hardly any scope for change, maintenance will be
very difficult. Therefore approach of development
should be the production of maintainable
software. All these problems translate to a huge
maintenance expenditure, which has been
estimated ranging from 40% to 70% of the total
cost during the life cycle of large-scale software
systems.
Potential Solutions to Maintenance Problems
A number of possible solutions to maintenance problems have
been suggested. They include: budget & effort reallocation;
complete replacement of existing systems; and enhancement of
existing systems.
Complete replacement of the system is not usually a viable
option. An operational system in itself can be asset to an
organization in terms of the investment in technical knowledge
and the working culture engendered. The current system may
need to have the potential to evolve to a higher state, providing
more sophisticated user-driven functionality, the capability of
developing cutting edge technology, and of allowing the
integration of other systems in a cost effective manner.
Budget and Effort Reallocation
It is now-a-days suggested that more time and resources
should be invested in the development-specification & design
3E.253
of more maintainable systems rather than allocating resources

SOFTWARE ENGINEERING TECHNIQUES

to develop unmentionable or difficult to maintain systems. The
use of more advanced requirement specification approaches;
design techniques & tools, quality assurance procedures and
standards such as ISOP 9000, CMM and maintenance standards
are aimed at addressing this issue.
Complete Replacement of the System
If maintaining an existing system costs as much as developing a
new one, why not develop a new system from scratch. This
point of view is understandable, but in practice it is not simple.
The risk and costs associated with complete system replacement
are very high. Corrective & preventive maintenance take place
periodically at relatively small but incremental costs. Some
organization can afford to pay for these comparatively small
maintenance charges while at the same time supporting more
ambitious and financially demanding project may not be
possible.
The creation of another system is no guarantee that it will
function better than the old one. On installation, errors may be
found in functions the old system performed correctly and such
errors will need to be fixed as they are discovered.
Notes

© Copy Right: Rai University

3E.253 69