- - -- --- -~~ --- ----.

software Ma int en an ce

re mainte nance is a task that every develop ment h

Sof!,"'~d to the custom er's ·te installe d and is operaf~ o:ip T~=rto face wb_eo the softwar e ia.
Th ~fore, delivery or release of
-~:g
del•ve re inaugu rates the mainte nance phase of the ife c~le
softwar e operat ional after release is very sigrufic~nt e d e spent and effort require
tee':,st of the entire life cycle. Despit e the fact that it is very imanp rt n~um~sc~b~ut
o a n a n a e
40-70% of
ngmg
d

as .
t}le l d h '
r, routinely the poor y manag e eadach e that nobody wants t o do.
at IS

g,1 WHAT IS SOFTWA RE MAINT ENAN CE

, it means
The term mainte nance is a little strange when applied to softwar e. In common speech
from
filing things that break_ or wear out. In softwa re, nothing wears out; it is either wrong
tenn is
the beginning, or we decide later that we want to do someth ing differen t. Howev er the
common that we must live with it [LAMB 88]. '
80
e-
Softwa re mainte nance is a very broad activity that include s error correcti ons, enhanc
78]. Becaus e
ments of capabil ities, deletio n of obsolete_capabil ities, and optimiz ation [STEP
making
cliange 1s mevita ble, mecha msms must be develop ed for evaluat ing, control ling and
red to
modifications. So any work done to change the softwar e after it is in operati on is conside
value
be maintenance work. The purpos e is to preserv e th.e., value of software over time. The
can be enhanc ed by ~xpand ing the custom er base, ~eetin g additional cequirements,_becoming
for 20
easier to use, more efficien t and employ ing newer technology. Mainte nance may span
years, wherea s develo pment may be 1-2 years.

9.1.1 Catego ries of Mainte nance

computer
The only thing that remain s consta nt in life is "CHAN GE". AB the specification of the
systems change , reflecti ng change s in the externa l world, so must the system
s themselves.
ed by
More than two-fif ths of mainte nance a ctivitie s are extensions and modifications request
ed below:
the users. There are four major categor ies of software mainte nance, which are discuss
1oCorrecti
.
ve mainte nance
. ~
from design
l:C.·D~ refe~ to modifi cations initiate d b defects in the softwar e. A defect can result
softwar e
errors, !2fil errors and codi ~ errors. Design errors occur when cha nges made to the
.
are incorrect, incomp lete, wrongl y commu nicated or the change request is misunderstood
of design
Logic errors result from invalid t est s and conclusions, incorre ct implem entation
incon ect
specifications, faulty logic flow or incomp lete t est dat a . Coding errors are caused by

459
 460 Software Engi n e ~
-~ . .. ., . 46f]
imp lementation of d etailed logic d esign a nd incorrect u se of the source cod e logic. Defects nrc , ctivity 1s us ually imtinled from within the maintenance organizat;on with the
100 0
also caused by dat.n processing errors and system performnnce errors ILI EN 80]. _This /making program easier to u nderstand a nd hence facilitating future mointennnco
1n the event of system failure due to a n en·or , actions ere taken to restore op ernlion of 1ntent . . eludes code restructuring, code
k This tn ft h -
. - -,- - and documentation
- I optimization updating. After
the software system . Due to pressure froni management. mainlenn cc p ersonnel som etimes .,,or ·88 0 f ·ck fixes to so wore, t e comp e.XJty of its source code can increase to an unman-
res ort to emergency fixes known as "patching" !BENN 91]. The a dhoc\nature of this approach • 111ri q~ thus justifyfog complete restructuring or the code. ,Code optim~ioii)can be
often gives rise to a r ange of problems th at include increased program complexity and unfore- .,.-
_-able ed h
levtoe 'e noble the p rograms to. run faster ... ~t""us--e-o""f~s=-=to-rn-=ge. Up-
or to make more effi:;:,,..c,,·e-n
seen ripple e ffects ITAKA 961.(!:Jnforeseen ripple effects imply that n change to one p o ~ perforlD and syste m documentation, t ough frequently ignored, is oflen necessary when
program m ay affect other sections in an unpredictable m_nnner , there by leading to distortion c1aunr O software
use; is changed. The documents affected by the change should be modi6ed to
anY port th urrent state of the system ITAKA 96).
in the logic of the system) This is often due to lock of l lille to car ry out a through •;mpnct
analysis" before effecting the change. · .
renec:tThee crequests come regularly to.carry out maintenance activities. The request may be for
. d tive or perfective momtennnce. However most of the requests are for perfec-
2 • Adapti ve fT!Blntena nce corrective, a ope. The dis tribution is shown in Fig. 9.1 [LIEN 80).
·ntenonc
lt indudes modifying the software to match changes in the eve--c-cbonging e11vironment. The tiVO mo• t es of maintenance" is required, as mentioned earlier , to reduce the complex-
term environment in this context refers to the totality of all conditions nnd influen ces which "Oth:r ~his is not very high as s h own in Fig. 9.1, because, we may not get any extemnl
act from outside upon the software, for example, busin ess rules, governme nt policies, work it)' of the
reque& co ehi.. s a ctivity and this is confined to maintenance organization only.
ts fort
patterns, software end h a rdware operating platforms. A change to the whole or part of this
en vironme nt w;LI require a corresponding modification of the software [BROO 87 ].
Thus, this type or maintenance includes any work jnjtjat.ed as fl consequence of moyjng
the soft.ware to a dj(Tecrot h a rdware or software pJatform-compilcr. operating system or neiy_
_E.roccssor . Any change in the government policy can have far-reaching r amification s on the
software. When European countries had decided to go for "single European currency", this
change affected alJ banking system software end was modified accordingly.

~c Perlcc tlve m ain tenan c e

It means limproving processing efficiency or performance. or r estructllr!,n g~e ~oftware to
improve changeabilitB When the software becomes useful, the user tends to experiment with
n ew cases beyond the scope for which it was initially developed. Expans ion in requirements
can take the form of enhancement of existing system functionality or improvement in compu-
tational efficiency; for ex.ample, providing a Management Information System with a dala
entry module or a. new message handling facility [STRI 82).
He nce, perfective maintenance refers to enhancements: making the product better , faster,
s maller, bette.r docume nted, cleaner structured, Mth more functions or reports.
Other types o f m ain tenance ~t0 tt1J.·.,t
Yo
There are long term effects of corrective, adaptive and perfective changes. This leads to in-
crease in the complexity of the software, which reflects d eteriorating structure. The wor k is
,,..J required to be done to maintain it or to reduce it, if possible. This work m ay b e n amed as
\_preventive_!D~~nence. This term is oft.en u sed with hardware systems and impljes such
thfogs as lubricationor parts before need occurs, or automatic replacement of banks or light
bulbs before they start to individually burn out. Since software does not d egrade in the same
way es hardware !Ind does not n eed maintenance to retain the presently established level or
functionality. Some a uthors do not use this term. That is why we have incl uded this type or
activity u n d er "OLher Types of Ma intenance" category.
Fig. 9 .1: 01sInbut1on ol IT\.11n1enance elfon
9.1.2 Proble ms D uring Maintenance
The most important proble m during maintenance is that before correcting or modifyfog n
program, the programmer must first understand it . Then, the programmer must understand
_ the impact of the intended change. Few problems are discussed below [LEHM 85, ARNO 821:
toot IJOT • Often the program is written by soother. person or group of persons working over the
1t1,~1>Molti years in isolation from each other. ~1 N" • • •
• Often the program is changed by person who did not understand it clearly, resulting
11
''"' •~
l>Cl•UHD~ • a d e t enora
m . .
. . al orgaruzation.
· t·ton of th e program's ongm
• Program listings, even t h ose t hat are well orgnnized, are not structured to support
1
IIOT " ~ ~eading for compre h ension. We nor mally rend sn article or book straight through,
but w;th listing, pr ogrammer rummages back and forth.
• There is a high stafT turnover w;thin information technology industry. Due to this
.ttrn., EFFE<.r many systems are maintained by persons who are not the original authors. These
persons may n ot have adequ ate knowledge about the system. This may mean that
these persons may introduce changes lo programs without being aware of their effects
on ot her parts of t h e syste m the ripple elTect. This problem mny be worsened by the
abse nce of docume ntation. Even whe re it exists, it may be out of date or inadequate.

__,,
 462 Software Englnee~ Eare Maintenance
463 1
• Some problems only become clearer when a system is in use. Many users know what The key lesson to learn from these studies is that most m aintenance can be managed.
they want but lack the ability to express it in a form understandable to progra mmers/ C rtainly the 79% in the adaptive, perfective and preventive categories can be anticipated,
analysts. This is primarily due to information gap. ~eduled, monitored, estimated and managed. From the Table 9.1, we see t hat at least some
• Systems are not designed for change. If there is hardly any scope for change, mainte- 0
~the corrective mniotenance activities can also be managed. We may say, only about 10% of
nance will be very difficult. Therefore approach of development should be the produc- aintenance requests r eally r equire special and immediate handling. The other 90% requests
tion of maintainable software. :n be handled in en organized and routine managerial system.
All these problems translate to a huge maintenance expenditure, which has been esti- If we do proper and timely preventive maintenance, this 10% emergency requests may
mated ranging from ~ % of the total cost during the life cycle of large scale software aleo be minimised. The preventive maintenance would involve assigning some time ofmeinte-
sys tems [STEP 80). ce persons to r e-examine a product that has been modified several times to evaluate whether
?:Structure can be r econstituted, cleaned up, or enhanced in anticipation of further mainte-
9.1.3 Main te nanc e is M an ag eable ~ance. Preventive maintenance may cost, but it produces a real benefit to reduce the mainte-
A co=oo misconception about maintenance is that it is not manageable. We cannot control nance activities.
it. Every fix is different, end it is like hysterical phone calls at 2.00 in the morning. "lY
The data obtained by Lientz end Swanson [LIEN 80] suggested other side of~einte- 9.1.4 Potent ia l Solut ions t o Maintenance Problems
nence work. In their survey, they investigated the distribution of effort in software mainte- A number of possi ble solu~ons to maintenance problems have been suggested. Tbey include:
nance. The results are given in the Table 9 .1. budget and effort reallocation ; complete replacement of existing systems; and enhancement of
existing systems.
Table 9.1 : 0 1slnbu1ton of maintenance eNort
l O Budg et and effort reallocation
1 Emergency debugging 12.4%

2 Routine debugging 9.3% It is now-a-days suggested that mor e time and r esources should be invested in the development-
specification end d esign of more maintainable systems rather then allocating resources to
3 Data environment adaptation 17.3%
develop unmaintainable or difficult to maintain systems. Tbe use ofmore advanced requirement
Changes in hardware and OS 6.2% specification approaches [BOTT 94], design techniques and tools [ZEVG 95], quality assurance
Enhancements for users 41.8% procedures end standards such as ISOP 9000, CMM and maintenance standards are aimed at
•5
5.5% addressing this issue.
6 Documentation Improvement
7 Code efficiency improvement 4.0% 2 <;omplete replacem ent of the system
0

8 Others 3.5% If maintaining an existing system costs es 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 oot simple.
It is clear from the Table 9. 1, only 12.4% of effort is devoted to emergency debugging. Of The risk end costs associated with complete system replacement are very high. Corrective end
course, getting a call at 2.00 in morning is more memorable than getting a request for an preventive maintenance take place periodically at relatively small but incremental costs. Some
innocuous modification in a report format. organizations can afford to pay for these comparatively small maintenance charges while at
Another item in the survey of Lientz aod Swanson asked about the kinds of mainte- the same time supporting m or e ambitious and financially demanding projects may not be
nance requests that are made in the companies. These results are given in table 9.2. possible.
The creation of another system is oo guarantee that it will function better than the old
T:ible 9.2 : Kinds of mainle'Jance requestS
one. On installation, errors may be found in functions which the old system performed cor-
1 New report,, 40.8% rectly end such errors will need to be fixed as they are discovered.
27.1%
2
3
Add data in existing reports
Reformed reports
- 10%
3.. Maintenan c e o f existing system
Complete replacem ent of t he system is not usually a viable option. Ao operational sys tem in
Condense reports 5.6% itself can be en asset to an organization in terms of the investment in technical knowledge end
• the working culture en gendered. The curren t system may need to have the poten tial to _evolve
5 Consolidate reports 6.4% to a h igher state, providing more sophisticated u ser-driven functionality, the cepa_b ility of
6 Others 10.1% developing cutting edge technology, and of allowing the integra tion of other system s ID a cost
effective manner .

- ~
1464 Software Engineering

e
".
the program and is usually based on the
4
9.2 THE MAINTENANCE PROCESS 1·,am nsure ol the effort required to understand ..
contro1 or data now of the
. . program.
h The
..aelf-descnptaveness of the program is a measure of
Once particular maintenance 'l,2iectiye js estnblishcd, the maintenance personnel must first I ar the program ts, 1.e. , ow eaRy at as to read' UJ1derstand' and use.
howce
understand ~hat they are to modifv. They must then modify the program to satisfy the main-
ter,ance objectives. Mer modification, they must ensure that the modification does not affect Maintenance Propo:.al
9 2 2 Generating Particular
other portions of the program. Finally, they must test the program. These activities can be • ' econd phase cons1s ·
. Iar maintenance
· ts of generat·1ng a partacu proposa l to accomp1a·s h t he
accomplished in the four phases as shown in Fig. 9.2 [STEP 80]. :n,eJ:rnentation of~he maintenance objective. Thi~ requires a clear understanding of both t_he
Correct program error im~ tennnce objective and the program to be modified. However, the ease of generating main-
rn8lfl e proposals for a program is primarily affected by the attribute extensibility. The extcn-
Add new capabllilles
.
~n_anli/Y of the program
s1b1 is a measure of the extent to which the program can support extensions
Determine maintenance of critical functions.
objeciive 1--...::::: Delete obsolete features
Opllmlzallon
g,2.3 Ripple Effect
Phase 1 The third_ phase consis ts of accounting for all of the ripple effect 88 a consequence of progrnm
Complexity modifications. In software'. the effect of a modification may not be local to the modification, but
may also affect other portions of the program. There is a ripple effect from the location of the
Program I Documentation modification to the other parts oftbe programs that are affected by the modification [COLLO 78].
understanding One aspect of this ripple effect is logical or functional in nature. Another aspect of this ripple
effect concerns the performance of the program. Since a large-scale program usually has both
Self descriptiveness
Phase 2 functional and performance requirements, it is necessary to understand the potential effect of
a program modification from both a logical and a performance point of view. The primary
attribute affecting the ripple e_~ect _as a consequence of a program modification is the § biliTu
Generate particular
ITl8Jlllenance proposal I Extensibllily of the program. Prggram stability 1B .defined as the resistance to the amplification of changes
i!;_the progr~-- ----

Phase 3 9.2.4 Modified Program Testing

~uni IQ_r_!ipple_ I Stability The fourth phase consists of testing the modified program to ensure that the modified program
effect has at least the same reliability level as before. It is important that cost-effective testing tech-
- - niques be applied during-maintenance. The primary factor contributing to the development of
Phase 4 these cost-effective techniques is the testability of the program. Program testability is defined
as a measure of the effort required to adequately test the program according to some well
Testing
I Testability defined testing criterion.

No
Fig. 9.2: The sohware ma,ntenance process
9.2.1 Program Understanding
The first phase consists of analyzing the program in order to understand it. Several attributes
such as the complexity of the program, the documentation, and the self-descriptiveness of the
program contribute to the ease of understanding the program. The complexity of the program
9.2.5 Maintainability
Each of these four phases and their associated software quality attributes are critical to the
maintenance process. All of these factors must be combined to form maintainability. How easy
is it to maintain a program? To a large extent, that depends on how difficult the program is to
understand. Program maintainability and program understandability are parallel concepts:
the more difficult a program is to understand, the more difficult it is to maintain. And the
more difficult it is to maintain, the higher its maintainability risk. Maintainability may be
defined qualita tively as: the ease with which solhvare can be understood, corrected, adapted,
~
 ~t
[ 466 Software Englrieenng
~'"'"""00 . . . . 467J
9.3 MAINTENANCE MODELS Ce
requirements were
the mot1vat1on for this was the eriVJronment where ~
v
..... ..riot
Maintenance is nothing but development and requires special skills. Many times, mainte.
to 11181°
. tenantood, and a full system could not be built. ----.....
nance activities are performed without requirements or design documents. Sometimes it . ted for m aintenance, the model assumes complete documentation as it relies on
\ ~
also difficult to understand the old code. Therefore, the need of maintenance models has be:: -.1:r.cat1on .
A ~p of this as the starting point of each iteration. The model is effectively a three-
!DOW"
gl: 1e as shown in the Ftg. 9.4.
recognized, but presently, the models are neither so well developed nor so well understood as o/
models for software development. V _Analysis
Characterization of propos~d modifications
9.3.1 Quick-fix Model I
v Redesign and implementation
This is basically an adhoc approach to maintaining software. It is a fire fighting approach ~
waiting for the problem to occur and then trying to fix it as quickly as possible. The model i~ \__ Analyze existing system
.
shown in the Fig. 9.3.
Problem
found
Redesign current
version and Charactenze
implementation proposed
modlflcaUons

FllClt Ag. 9.4: The lhree-stage cycle ol ,tcraove enhancement

Fig. 9.3: The qu,ck-fix model
. ·,
In trus model, fixes would be done ~bout detailed analysis of the long-term effects, for
example, ripple effects through the software or effects on the code structure. There would be
little, if any documentation. Where are the advantages of such a model and why it is still used?
In an appropriate environment it can work perfectly well. If, for example, a system is devel-
oped and maintained by sin le person, e or she can come to learn the system well enough to
be able to manage without detaile ocwnentation, to be able to make m_stinctjve judgements
about bow and how not to implement change. The job gets done quickly and cheaply. This is
normally used due to pressure of deadlines and resources.
If customers are demanding the correction of an error they may not be willing to wait
for the organization to go through detailed and time-consuming stage of risk analysis. The
~aoizatioo roa;v nm a bigher rj§)c in keeping its customers waiting than it runs in going for
the quickest fix. But what of the long-term problems?
If an organization relies on quick-fix alone, it will run into difficult and very expensive
problems, thus losing any advantage it gained from using the quick-fix model in the first place.
We should distinguish the short-term and long-term upgrades. If a user finds a bug in a
commercial word processor, for example, it would be unrealistic to expect a whole new upgrade
immediately. Oft.en, a company will release a quick-fix as a temporary measure. The real
solution will be implemented, alongwith other corrections and enhancements, as a major
upgrade at a later date [TAKA 96].
9.3.2 Iterati ve Enhan cement Model
In this model, it has been proposed that the changes in the software system throughout its
lifetime are an iter ative process. Origina lly proposed as a development model but well suited
The existing documentation of each stage (requirements, design coding testing and
analysis) is modified starting with the highest-level document affected by Uie prop~sed changes.
These modifications are propagated through the set of documents and the system redesigned.
u_ie mode) exp)jcitly supports reuse and also accommodates other roodc]11, far example the
quick-fix model.
The pressure of the maintenance environment often dictates that a quick solution is
found but, as we have seen, the use of the quickest solution can lead to more problems than it
solves. In the first iteration problem areas would be identifies! and next iteration would spe-
cifically·address the problem. a+
Theproblems with this model are the assumpa6ns made about the existence of full
documentation and the ability of the maintenance team to analyze the existing product in full.
Wider use of structured maintenance models will lead to a culture where documentation tends
to be kept up to date and complete, the current situation is that this is not often the case.
9.3.3 Reuse Oriented Model
This model is based on the principle that maintenance could be viewed as an activity involving
the reuse of existing program components. The reuse model [BAS! 90] has four main steps:
~dentification of the parts of the old system that are candidates for reuse.
~ derstanditlg these system parts.
AiiJModificatioo of the old system parts appropriate to the new requirements.
~ Integration of the modified parts into the new system.
A detailed framework is required for the classification of components and the possible
modifications. With the full reuse model the starting point may be any phase of the life cycle-
 Software Engineering
sc,IIW8re
1468 ~"'6 .. ~
the requirements, the design, the code or the test data-unlike other models. (The mode) i W.,, ;, """"'out.Thus the m,;,te,,oe, pro,,., Odri,., by th,"""""""" ts-:-
-
-•intenancde 'sions:J which are based on the balan~- of objectives -against the ~ n~
shown in Fig. 9.5) For example, in the quick-fix model, the starting point is always the code.s r's eci
-~
t Maintenance Model
Otd system g,3.5, Tau e developed by B.J. Taute in 1983 and is very easy to understand and implement.
/ ~ Nn-m
. a typica
'l'he mode! w;:aintenance model and has eight phases in cycle fashion. The phases are shown
Requlrwnents analysis It iS
1' R·-•·•M--0 in Fig. 9.7.
Design Components Design
library '---
Change requw I/
Source cOde

Tesl dala \ J;;~ ta

Ag. 9 5: Thi' reuse modl'I

Operation

9.3.4 Boehm"s Model

ln 1983 Boehm [BOEH 83] proposed a model for the maintenance process based upon the ~
economic models and principles. Economic models are nothing new, economic decisions are a
Documenlatlon Release
major driving fon;e behjnd many processes and Boehm's thesis was that economic models and
,rinciples~uld-not onlx improve productivity in the maintenance but also help understantl- ~!f.0(€ fi) Ag. 9.7: Taule ma,n1enance model
ng the process.
(i) Change request phase: Maintenance team gets a request in a prescribed format
Boehm represents the maintenance process as a closed loop cycle as shown in Fig. 9.6. from the client to make a change. This change may fall in any category of maintenance activi-
He theorizes that it is the stage where management decisions are made that drives the process. ties. We identify the type of request (i.e. corrective, adaptive, perfective or preventive) and
In this stage, a set of approved changes is determined by applying particular strategies and assign a unique identification number to the request.
cost-beMfit evaluations to a set of proposed changes. The approved changes are accompanied
(ii) Estimate Phase: This phase is devoted to estimate the time and effort required to
by their own budgets, which will largely determine the extent and type of resources expanded.
make the change. It is difficult to make exact estimates. But our objective is to have at least
reasonable estimate of time and effort. Impact analysis on existing system is also required to
Management decisionl minimise the ripple effect.
I ~
(iii) Schedule phase: We may like to identify change requests for the next scheduled
release and may also prepare the documents that are required for planning.
(iu) Programming phase: In this phase, source code is modified to implement the
1
1' I Change Implementation requested change. All relevant documents like design document, manuals etc. are updated
[ Evaluation I I
I Results
--r y-- New version of
software
a~rd.ingly. Final output is the test version of the source code.
(u) Test phase: We would like to ensure that modification is correctly implemented.
Hence, we test the code. We may use already available test cases and may also design new test
cases. The term used for such testing is known as regression testing.
fl .
Software in use (ui) Documentation phase: After regression testing, system and user documents ore
I prepared/ updated before releasing the system. This helps us to maintain co-relation between
I
Ag. 9.6: Boehm's model code and documents.
~ (uii) Release phase: The new software product alongwith updated documents are
f Boehm sees the maintenance manager's task as one of balancing the pursuit of the delivered to the cus tomer. Acceptance testing is carried out by the users of the system.
l objectives of maintenance against t,.lie Eonstr.ain~ impo~ed by the environment in which

....
 ~-te_na_nce
_ _ _ _ _ _ _ _ _ _ _ ~ - -- - -- - - -
[ 470 Software Engineen'!J
_-----~•1~17
~ ple !J.l .:J
11111
(viii) Operation phase: After acceptance testing, software is placed under normal opern- development effort for a software project . 50
tion. During usage, when another problem is identified or new functionality requirement is 'l'b'~ constant (K) iB 0.3. The complexity of th:sod o_per~on-months. The empirical) d
"f C e IS qwte hi h . y eter-
felt or enhancement of existing capability is desired, again a 'Change request' process is initi- tbe total effort expen de d (M) I g and IS equal to 8. Calculate
ated. If we do so, we may go back to change requrest phase and repeat all phnses to implement (i) maintenance team has good level of und .
the change. erstandmg of th ·
(ii) maintenance team has poor understandin . e proJect (d = 0.9)
. g of proJect (d = 0.1).
sc,Jut1on
9 :4 ESTIMATION OF MAINTENANCE COSTS Development effort (P) = 500 PM
K=0.3
We had earlier discussed that maintenance effort is very significant and consumes about 40-
70% of the cost of the entire life cycle. However, this cost may vary widely froll). one application C=8
domain to another. (i) Maintenance team has good level of unden;taodio _
It is advisable to invest more effort in early phases of software life cycle to reduce the M = p + K ef<-dl g (d - 0.9)
maintenance costs. The defect repair ratio increases heavily from analysis phase to implemen- = 500 + 0.3 e<S--0.9>
tation phase and given in the Table 9.3.
= 500 + 363.59 = 863.59 PM
Table 9.3: Dcf~t repair rallo
(ii) Maintenance team has poor level of unden;taodiog (d = O.l )
Phase
M=P+Ke<Mli
Ratio
= 500 + 0.3e'8-0.I)
Analysis 1
= 500 + 809.18 = 1309.18 PM
Design 10
Hence, it is clear that effort increases
.. ,.__
exponentially, if poor so1sware . .
engmeenng
Implementation 100
approaches are used and understandability of the project is poor.
Therefore more effort during development will certainly reduce the cost of main-
tenance. Good software engineering techniques such as precise specification, loose coupling 9.4.2 Boehm Model
and configuration management all reduce maintenance costs. Boehm [BOEH81] proposed a formula for estimating maintenance costs as part ofhis COCOMO
Model. Using data gathered from several projects, this formula was established in terms of
9.4.1 Bclady .ind Lehman Model effort. Boehm used a quantity called Annual Cbaoge Traffic (ACT) which is defined as:
This model indicates that the effort and cost can increase exponentially if poor software "The fraction of a software product's source instructions which undergo change during a
development approach is used and the person or group that used the approach is no longer year either through addition, deletion or modification".
available to perform maintenance. The basic equation [BELA 76] is given below: The ACT is clearly related to the number of change requests.
M =P+ Ke<r-<t> ACT - KLOC,dded + KLOCd.ie...i
where KLOC..1a1
The Annual Maintenance Effort (AME) in person-months can be calculated as:
M Total effort expended.
AME = ACT x SDE
P Productive effort that involves analysis, design, coding, testing and evaluation.
where, SDE : Software development effort in person-months.
K An empirically determined constant.
ACT : Annual change Traffic
c Complexity measure due to lack of good design and documentation.
Suppose a software project required 400 person-months of development effort and it
d Degree to which maintenan~ team is familiar with the software. was estimated tbat 25% of the code would be modified in a year. The AME will be 0.25 x 400
In this relation, the value of'c' is increased if the software system is developed without · = 100 person_month. Boehm suggested that this rough estimate should be refined by judging
use of a software engineering process. Of course, 'd will be higher for a large software product the importance of factors affecting the cost and selecting the appropriate cost multipliers.
with a high degree of systematic structure than a small one with the same degree. ¢.
Using these factors, Effort Adjustment Factor (EAF) should be calculated as in the case of
If the soft.ware is maintained without an understanding of the structure, function, and pur- COCOMO model. The modified equation is given below:
poee of the software, then the value of 'd' will be low [SAGE 90). AME = ACT * SDE * EAF

_::..;.i
 ~tenance
472 Software Enginee~ ~ 473]
~ EGREcc::1n N T ESTINr.
Example 9 .2
l:.,,ft<fla ;nevitably changes, how so ever well written d . .
Annual change traffic (ACT) for a software system is 15% per year. The development effort is
600 PMs. Compute an estimate for annual maintenance effort (AME). If life time of the project ~aredaotiware is required to be retested in order to an designed ,t may be initia lly. Thia
~-nd ensure that ch
is 10 vears, what is the total effort of the project? a nges work correctly and
.
_..ch, gcs have not adversely affected other parts · flh ft:ware Thia
.......s an o c so
ua-· ch nges in one part of a software may have subtl d . · JS necessary because
Solution _.II ad parts of the software. e u.n es,red effects in other seemingly
The development effort = 600 PM unretate
When we develop software, we use development testin to b .
Annu al change traffic (ACT) = 15% 0
of the software. Development testing involves con t · tam confidence in the cor-
t!
Total duration for which effort is to be calculated = 10 years. ,ectne;: uld we test the software, and then, designing an: c ,~g a tes_t plan that describes
The maintenance e ffort is a fraction of development effort and is assumed to be constant. 8
bO~fy th oe requirements of the test plan. When we modify ftrunrung sw"'.' of test cases that
AME = ACT x SDE ..t.18 · · so ware, we typically retest it This
•<ng is called regression testing. Hence, "Regression testing is th f .·
= 0 .15 x 600 = 90PM ,:et.es.. ft d . e process o retesting the
inodilied parts of the :o ware an ensunng that no new errors have been introduced into
Maintenance effort for 10 years = 10 x 90 = 900 PM. ·ously tested code •
Total effort = 600 + 900 = 1500 PM. p,:eVl . te tin
Therefore, regression s g tests both the modified code and other parts of the pro-
Exampl e 9 .3 ,raJ!l that may be affected b:' the program change. It serves many purposes such as to:
A software project has development effort of 500 PM. It is assumed that 10% code will be • increase confidence m the correctness of the modified program
modified per year. Some of the cost multipliers are given as: • locate errors in the modified program
(i) Required software Reliability (RELY): high • preserve the quality and reliability of software
(ii) Date base size (DATA) : high
• ensure the software's continued operation.
(iii) Analyst capability (ACAP) : high
(iu) Application experience (AEXP) : Very high _ _ D evelopment Test ing Vers us Regression Testing
951
(u) Programming language experience (LEXP) : high We typically think of re_gressio'.' testing as a software maintenance activity; however, we also
Oth er multipliers are nominal. Calculate the Annual Maintenance Effort (AME). rfonn regression testing dunng the latter stages of software development. This latter stage
Sol ution ~ after we have developed test plans and test suites and used them initially to test the
Annual change traffic (ACT) = 1091, software.
Software development effort (SDE) = 500 PM During this stage of development, we fine tune the code and correct errors in it, hence
Using Table 4.5 of COCOMO model, effort a djustment factor can be calculated given our activities resemble maintenance activities. The comparision of both is given in Table 9.4.
below: Tablo 9 .4 : Companslon ol development and regress10n tesllng techniques
RELY= 1.15
Deuelopment testing R egression testing
ACAP = 0.86 Sr. No.
We create test suites and test plans. We can make use of existing test suites and
AEXP=0.82 1.
test p lans.
LEXP =0.95
We test all software components. We retest affected components that have been
DATA= 1.08 2.
modified by modifications.
Other values are nominal values. Hence,
Budget gives time for testing. Budget often does n ot give time for regression
EAF = 1.15 x 0.86 x 0 .82 x 0 .95 x 1.08 = 0.832 3.
testing.
AME= ACT • SDE • EAF
= 0.1 • 500 • 0.832 = 41.6 PM 4. We perform testing just once on a software \Ve perform r egression testin g many times
over the life of the software product.
AME= 41.6 PM product.
Pe rformed in crisis situations , under greater
6. Performed under the pressure of release dote
time con s traints.
of the soft.ware.
 .,.,.... Maintenance
[ 474 Software Enginee~ ~ rnilUJlllZation
· methods can omit so - ·- .- - - - -~ 475
}{ence me test cases th
9.5.2 Regression Test Selection . eel soft.ware a nd so, they a re not safe. We should be car a~might elt]lose fault in the
t cases and always try to use safe regress"t eful in the Process of m· . .
teS
..,o4i6r
Regression testing is very expensive activity and consumes significant amount of efforVcost. on test select"100 lntmJZ3.
liOO O --"e regression test selection technique • . technique.
Many techniques are available to reduce this effort/cost. Simplest is to reuse the test suite that /. Ill'-'' . . · is one that d
test case from the ongmal test suite that , un er certain assumpti
was used to test the original version of the software. Re-running aJJ test cases in the test-suite ,....ts evetY can expose faull!; in th . ons, se-
however, may still require excessive time. ' ...-()'l'll96]. e modified program
An improvement is to reuse the existing test suite, but to apply a r egTession test selec- ta ctive Retest Techniques
tion technique to select an appropriate subset of the test suite to be run. If the subset is sma]J I
.3 see
enough, significant sa,'lllgs in time are achieved. To date, a number of regTession test selection t,5 . test techniques differ from the "retest-all" tech . .
....1ec:ttve re ·te ntque, which reruns all tes•· . h
techniques have been developed for use in testing procedural and object oriented languages. ~ . test sw • .., 1n t e
Testing professionals are reluctant, however, to omit from a test suite any test case that ~ S )ective retest technique may be more economical than th "
e ting
a reduced sub set of tests to run is less th th e retest,.al)• techmque• .
might expose a fault in the modified software. Consider, for example, the code fragments and ___. 0 f se)ec . if the
Cl"'" lective retest technique lets us omit.
an e cost of runnia th
associated test cases in Fig. 9.8 and Fig. 9.9 respectively. In Fig. 9.8, fragment B represents an g e tests thnt
erroneously modified version of fragment A, in which statement S is modified. these Selective retest te hn" ··
5 c iques partition an existing test suite into subs . .
We execute test cases t 3 and t 4 , where both execute statements S and S ' Test case t retestable, and obsolete test cases. Reusable test case . ets containing
5 5 bl e, . s exercise only unmodifi d
3 tr
re
usa roodified
causes a divide by zero problem in S5', whereas test case t does not.
4 specifications, and do not need to run but may be sa d , . e code
and.un sessions. Retestsble tes t cases . ' ve ,or reuse 1n subsequent
~ntA
exercise modified code or test difi d . .
Frag~nt B t,attng b I te t . . mo e specification and
(modi{ud form of A) be repeated. 0 so ete s cases either (1) specify incorrect inp , _ tp t .
abOuld . • ( ••) l . u.,..,u u re1ations due
_..,.;,;cation modifications or u no onger exerose the pro"'"'"' compo ts pecifi .
SI y = (.x - 1) • (.x + 1) s,I y = (.x - 1) • (.x + 1)
to ~ . ...~ nen ors cations
ere designed to exercise. The test cases that are obsolete for the first call
tbeY w reason are ed
S2 if (y =Ol S 2' if(y=O) spec:!fication-obsolete test ca , and the tes~ cases that_are obsolete for the second reason are
S3 return (error) S' return (error) d coverage-obsolete test cases. Because 1t may be difficult to recognize obsolete test
3 e - ..
we may list some test cases as uncl assifie d. In addition cases,
to reclassifying existing tests, selective
s. else S' else
• retest techniques may create, or recommen.d creatio~ of, _aew_-structural or new-specification
test cases, that test the ~rogTam cons~cts or specification items which are not covered by
S5 return (; ) S 5' return C:s) eJisting test cases. Selective r etest techniques are broadly classified in three categories :
Fig. 9.8: code fragments A and B
1, Coverage techniques: They are based on test coverage criteria. They locate coverable
program components that have been modified, and select test cases that exercise these
Test cases comPonents.
Test number Input E.xecution history 2. Minimization techniques: They work like cove.rage techniques, except that they
select minimal sets of test cases.
ti .x = 1 SI' S 2 , S3
s. Safe techniques: They do not focus on coverage criteria ; instead they select every
'2 %= - 1 SI' S2 , S3 teat, case that causes a modified program to produce different output than its original version.
t, %=2 Si, S2, S5 Rothermal [ROTH 96a] identified categories in which regression test selection techniques
.x=O SI' S2' S 5 can be compared and evaluated. These categories are:
'• • inclusiveness
Fig. 9.9: Test cases for code fragment A of Fig. 9,8
• precision
If we execute all test cases, we will detect this divide by zero fault. But we have to
• efficiency
miaimi:re the test suite. From the Fig. 9.9, it is clear that test cases t and t have the same
3 4
execution history i.e. SI' S2 , S5_ Iffew test cases have the same execution history ; minimiza- • generality. .
tion methods select only one test case. Others may be selected for coverage elsewhere in the Inclusiveness measures the extent to which a technique chooses test cases that will
code. Hence, either t3 or t 4 will be selected. Ifwe select t , we lose the opportunity to expose the cause the modified program t o produce different output than the original program, and thereby
4
fault that t 3 exposes. upose faults caused by modifications.
 9 ·- ... ,11,g ~are Maintenance
Prl'cision meoi;ure!l lhe ob1l.ily of o technique lo ovoid choosinit le~l Co!les that will ·,
cauo;;e the mc,d11ied proi:,-nm to produce dilTerenl oulput lhon lhe originnl prowam. not
Efficie,ncy measures the computnlionnl cost, ond thus, prnclicnlity, of o technique.
-- ---- 4n J

Genernlity measures the ability of o technique lo hondle renlistic and diverse lnnguo r<::::~
. teslmg .
. opp1·1coltons. ge donialn
roni-truclo;, nrb 1tmrily complex modificntinm:, nn d T<'n11.sllc
Evoluotion ond comporision of existing techniques helps u s lo choose appropriate
"
lt'<-'hniqurs fur particulor npplicalions. C Mappmg I ' ,
I
For example, ifwe require very n>linble code, we may insist on a safe scl<-ctive technique
re[!::irdlrss of the cosl. On the other h and, if we want lo reduce the testing lime, we moy choose
~ l...__
',.
Programm,ng.,
tll.lnimizotion technique, even though in doinit so we moy foil lo select some lest coses thot lmpiemen1 domain
expose fnu]ts in the m odified program.

f ,g 910· , 1 ,ppnJt.,11
9.6 REVERSE ENGINEERING · · • · •1.·r"n ap,pi 'AJ 11t.O dnd <k..'T\J,n~ pr.JflfJ..m

~everse ~ni;ineering is the process followed in order lo find diflicuH, unknown a nd h 1'dd
mfonnol1on oboul a sollwnre syRlem. ll is bccomingimportont, s ince severo.l soll.wlll'e prod en
lock propl•r documenlotion, ond ore highly unstructured, or their structure has degr ~eta
Lhrou~h a series ofmoint.enance efforts. Moinlcnonce activities connol be performed~
ronIDl<'te undrc>iJ..noding of th<' 1mf\wn re ~ystem .
Appo~ntly. underst.onding i;oll.wllJ'C looks o trivinl ~ sk , but in the absence of ony external
documenl.nt1on or dues, U1e t.osk oil.en becomes almost impossible.
9.6 .1 Scope and Tasks
Smee lhe main purpose of reverse e ngineering is to recover infonnotion from the existing code
or ony other inlerm<'dinte docume nts, any activity thol requires program understanding at
a ny level mny foll within tho scope of r everse engineering. What is achieved ns o res ult of any
n.'\'erl!e t•ngineering activity varies according to whot is going to be done with the extracted
mfom10t1on. The areas where reverse engineering is applicable include (but not limited to):
p~j!Tom rompn•hension, (ii) r:docu~nto.!:!_Q_I_)_ ond/or document generolion (iii) ~ r y of
<\!' >'il,'"ll UllllllUl.s:l! ond dl!llign details at any level of obslroction, (iv) identifying reui;oble comp<!_-
@
) t'nL-,, It•) identifying components that need ~slrucluri'!.![: (vi ) recovering business rules, .a nd
•ii) undt•r s ~ hi.:h-level system description. Processes attempting lo re-design, re-struc-
urc ond cnhnncc fu~t.ionalit/of a syst1>m orenol within the scope of reverse engineering.
Rever se e ngineering e ncom passes a wide array of tasks r elated to understanding and
t modifying soil.wore systl.'m s . This orrny of tosks con be broken inlo a number of classes. A few
of the>"e clnsscs nrc briefly di11cussed below:
• Moppi~g between concrete end obs1ract levels;. Software development process follows
from high-level abstraction to m d tai'l d d . . .
. e es1gn nnd concrete 1mplementnt1on. A
ore e
~evcrse engineer has to move backward nnd create llll abslrnct represcnllltion oft.he
1mplemenlotion from the mass or concrete details.
• Rediscovering high-level structures: A program is the embodiment of n well-defined
purpose and coherent high-level structure. However, the purpose and structure mny
be lost in couri;e of timr lllld through mainlcnllllce activities, such ns bw, fucin~._portui_:;,-
modifying nnd enhancement. One of lhe ta.sK.S of reverse engineering is to detect the
purpose and high-level structure of a program when the original one may have changed
and where, in foct, there may be no such specific pUTJ)ose left in the program.
• Finding missing links between program syntax and semantics: Computer programs
~re formal, in the serise they have well-defined syntnx lllld semantics. lo the formal
world, the meaning of a synloctical.ly correct program delennines the output for n
s pecific input. But systems that require reverse engineering g<'nerally would ha\le lost
their original semantics. Moreover, certain languages, such ns the objecl-oriented
languages, do not have str ong formal basis. Reverse engineering process s hould
determine the semantics or n given program from its syntnx.
• To extract reusable component: Based on the prcmis<' lhnt the use of !'xisting program
component.s can lead to no increase in productivity and improv!'ment in product qual-
ity [BIGG 891, the concept ofl'euse has increasingly become popular a mongst ~oft~~re
engineers. Success in reusing components depends in part on their ovn1labihty.
Reverse engineering tools nnd methods ofTer the opportunity to access nnd el\trnct
program components.

• Mnpptnl! between application nnd program domains: Compute r programs ore repre• 9.6.2 Levels of Reverse Engineering .
. t ts d~lhem with their
sPnt.nt ions of problem e1lunllons rrom some application domain. The programs us ually Reverse enoineers detect low-level implementation cons :rue an ~ l r t· of nn
.,. · - ll I incremenln ,onnn ion
d o not conloin nny hint about the problem. The tosk of the reverse engineer is l o ~ high level countcrp~s. The process eventun Y resulhtsl m anb "·d that the product of a
·=~,.;-.,....,-=-::::-::;.f Lh m It should none <' css, e no..,
tit rul'I tlw mopping from the npplication domnin lo the program dnmoin os sh own in over all nrch1Lecturc o c progra . . • h b t h' "her level of a~ n. If
. • does not necessarily nve to e a n i .,
Fig. ~J . 10. reverse engmeenng process . . em the o eration is commonly known us
it is nt Lhe some level ns the on gmnl syst d \ h p \Ling product is at a highcrlcvd of
"redocument.ntion" ICHII( 90\. If on the other han , e resu
 Sohware Engineering] E a r e Maintenance 479 ]
l 478
recognition of design decisions. E xamples of such construct.s are control and data structures,
abstraction. th e operation is known as "design recovery" IBIGG 891 or s pecification recovery as variables, pr ocedures a nd functions, defin ition and implemen tation modules, and class
shown in Fig. 9.11 ITAKA 96). hierarchies.

Abstrae1,on level Ul@CYde phase 9.6.3 Reverse Engineering Tools

RedOC\Jmenlation
High - ( SpedfallOn } J Reverse engineering is performed with the help of certain tools, otherwise doing the job manually
I
would require enormous amount of time and labour, rendering the whole purpose of it not only
SpecificalJOn useless but also expens ive. Rugaber [RUGA 94) iden tifies the following four basic components
·~----{ recovery of a r everse e nginee.r ing tool:
Reverse • The restructure r det ects poorly structured code fragments and replaces them by
Radoc:Umenla\JOn
engjnaer1ng equivalent s tructured code.
l DMll,I J:)
I
• The ~o_su:eferencer lists the places wher e each variable is defined and used.
• The static analyzer detects anomalous constructs su ch as uninitialized variables and
ON911-'Y
-- { dead code.
~ • The text editor and other simple tools suppo.r t browsing and editing of the sow,:e code.
: ) Redom1181Dtion
Low
........... In addition to th ese, a r everse engineering tool may incorporate graphical user-interface
and other visualization tools. In the following subsections, we shall look at two reverse
fl9. 1.11: ~ ol lbllraction
engineering tools.

Redocument.stlon • RIG/
Redocument.ation ~ d i e ~ equivalent representation within the same
of;;;:.utieallj
relative abstract.ion level [CHIK 90). The goals oCtbil procea are threefold. Firslli;, to create
alte~a_ti~e_views of the system eo u to ~'itn,.tancling,_for example file ~eneration ";?-
~ following phases:
a hierarchical Dta ftuWB w amtnil Dow diagram eourc:e code. Secondly. to improve cur-
~Q1 docurneolefim:i- Ideally, eucb documentation ebould have been produced during th-;-
development of the ll)'lltem and updated u the eyetem cbanged. Thia, unfortunately, is not
usually the cue. Thirdh~._t.o generate documentation for a newly ·modified program. This is
aimed at facilitating future miint41WlC8 work on the eyat.em; preventive maintenance.
Design recovery
De■ign recovery entaile identifying and utractinr meaoinpl biper-level abstractions
beyond thoee obtained directly from eurnination oCthe eource code (CBIK. 90). Thia may be
achieved from a combination or Gld&, eziemlc "9illJ docn:nrtetien, ...,,.e) experience, 'Uld
k n ~ e of the problem and ai>elia!:!!,D domains (BIGG 89]. The neo,end deaign-which is
not neceeearily the original deaign--can then be uaed for redevelopinc the ayatem. In other
word&, the reaulting design forme a bueline for future ayatem modificationl [GILLI 90). The
design could also be Wied to develop similar but non-identical applications. Far eumple, after
recovering the de■ign of a apelling cbeck(er) application, it can be uaed in the deaip of a apell-
checking module in a new word proceeeing package.
Different approaches, which vary in their focue, can be used to recover tbele clalip.
Some draw heavily on programming IB11guage q>nstructa contained in the Pl"Oll'IIID tin u
ieen in the model by Rugabe; et al. (RUGA 90]. They argue that an important aspect ofcllaip
recovery is being able to recognize, undentand and represent design deciaione present lo a
given source code. Program constructs-which vary between programming languagP~Dtb1e
The Rig:i System [MULL 92] is a n in teractive graph editor that p. rovides a graphical
representation of soft.ware systems. Th e Rigi approach t.o reverse engineering includes the
• Extracting syste ~mponents and relationships from source code to ~!te reso~
flow graphs. The extra ctic:m pliase is initially a u tomatic and involves parsing the source
code and s toring the extracted artifacts (i.e., datatypes, functions, dependencies) in a
repository. The rest of the phases in Rigi are semi-automatic in the sense it requires
user intervention.
• Creating subsyste~fr2!!!-the flow-graphs using graph edi.!!>r. Subsystem hierarchies
are built on top of t h e ini tial call graphs by using the subsystem composition
methodology, and s ubsystems are grouped into composite subsystems. These hierarchies
can be documented as views, which are snapshots of the various reverse engineering
states. Computing interfaces between subsystems by analyzing and propagating the
dependencies extracted from the source code.
• Evaluating subsystems for cohesion and cou pling and iterating until satisfactory
subsyste~s h a ve been cr eated. Rigi is useful for identifying hot-spots for maintenance
as well as candida te modules for reengineering. This information does not provide
insight t o the tool user on how to restructure the modules. The dynamic aspects of a
software system are not modeled in Rigi and therefore it is doubtful how well it would
perform for object-oriented languages.
 Sohware Engineering Software Maintenance
[ 480 ~
then graphically_disll.!file_§jgn,
migrate to a new platform (such as client-server), capture and
"Refine " language tools a nd re-docu ment poorly
- _ _ _ docume nted systems .
~
1n,ormotion • - - -
a fa~uly ofintera c~ivc, extensi bJ e development is the
Reason ing systems, inc. market s t.he Refine Langua~e Tools, The critical distinct ion between re-engineering and new softwar
eering code m progra mming languag es tncludi ng Ad e than start with a written
workbe nches for analyzing and reengin tarting point for the development as shown in Fig. 9. 12. Rather
s ofU1ese tools is that they a a, new system.
C, COBOL, and FORTRAN. One of the most attracti ve feature :pecification, the old system acts as a specification for the
lnngunge. Ench refine Ian re
custom izable to suit any particul ar version of the programnling
·n~:'.AP:::'.I:applic ation program ming inte~age
T=;;oo;li:;co'ii:mi;;es~,;;"~ith~=a=~=ul~h::•~d~oc~u~m~en~ted~~re,::e;n~gi~·=-=nee==::n: system br,ace)
l"o e tools use~nn intuitiv e X window f-l~:!!!
::==::- .J ased /
. .
mg cus miza ons:-R efine l11ngung;;~:::::
.•;::::~~~~,.: =r.i~i. :;:;;;i;.';::;-:;:: System Existing
c:i:aphical mtcrfac e and proVI e cupa cs 1~c u 1_ng: ' ~'.'°ctJ ve sourc~ _code naviga i specificaUon software
on re Orts (111) On.Tine vi ~ - system
(u) Genera tion of set/use i:tructure chart. and 1dent1fier definiti
al user interface
ana a standa ;~
and osLqcript printing of all reports, (i'ii)Consisten graphic
nrn)Rl jpn tp forward -engine ering CASE ~:~d
report lormat, and (U) Ability to e.~~es ign.inf
ant role in soft.war e mainte na nce. Good to0 ;8·
Reverse engineering plays a very signific
softwar e less expensi ve and less trouble some. Expe n.ence
can mnke. the task of maintni ning . ,
,or a softwar e system is ch
an d studies show that more than two-thirds oft.he money spent
nce of reverse engine e~ed Design and
up by mainten ance activities. In this backdrop, the role and importa implementation
ring tool can reduce the mainte nance co:~~g
attains a very high standin g. If a reverse enginee
it would save huge amount of money. Y
even a margin al amount , say 5%,
e development or i
Since reverse engineering is applicable at any phase of softwar
be effectiv ely employ ed at strateg ic points during softw ::
level of abstrac tion, it can
enable the developers to
development process . It would provide importa nt feedback and
t softwar e. Althou gh this wouf~
~ack, rectify faults, and design and implem ent more efficien
it would save much more from mainte nance expenses.
mcreas e development cost but eventually

9.7 SOFTWARE RE-EN GINEERING

mutate in ways that were never
~
(a) New software development (b) RHngineenng

System s that have been in the field for a long time evolve and nng
Fig. 9.8 : Compans1on ol new soltware development with re-eng,nee
ements are added, bugs fixed, and piece-m eal solution s tacked on, the once
planned. A. enhanc is carried out. Other
ve to mainta in. The costs of re-engineering depend on the extent of the work that
elegant system growa into eomething unmanageable and expensi the quality of the software , tool support availab le, extent of data
ea called legacy systems . factors affecting costs are;
Theae old -,.tema that muat atill be maintai ned are eometim conversion, availability of expert staff.
that technol ogy had to offer. But, as mission
Theae legacy .,.tema may havie been the beat p that system using
t.edmolo gy become s availab le, the uaen are faced with the The alterna tive to re-engineering a softwar e system is to redevelo
requirement.a change and better Where systems are very badly structur ed this may
already made in their existing modem software engineering techniques.
difficult problem of reamrilinr the )up investmenta they have option as the re-engin eering costs for these systems are likely to be high.
coat of mainten ance, cheape r technology be the only viable
system s against the promi1e aCbett.er deeipa. lower the legacy code:
of the legacy ayat.em s may be poorly structur ed The following suggestions may be useful for the modification of
and large improvement.a in capabilitiea. Most
may be either out of date or nolMZi ltenL The develop en of these • Study co~el l before attempt ing changes.
and their docume ntation
system s having left the organization; there may be no one
in the organiz ation who really • Concentrate on o_yerall control flow and not coding.
were alao not designe d for change . Another • Heavily «:Q!!!!!!fil!t internal code.
unders tands these syst.ema in detail. Thue l.)'ltema
ilability ofnqui rement l, deaip and test cases. • Create cr~efe rences
problem is the non-ava
legacy system s and tit • Build symbol tables
Softwa re re-engi neering ia concern ed with lfking existin g
lhem to .make them more maintai nabl!!, /ta a part of this nH!Dgineering process, effect of change.
i~pleme11ting • Use o_wn variables, constants and declarations !o localize the
may be tranala \ed t.o a more modem
the 1y1tem may be redocumen\ed 9,r_~ . It
e~ted on emting hardwa re technol ogy. Th~, softwar e re-
pro~'!l l)ling languige, implem
e, -reaJruc ture our old code,
enginee ring allows ua to transla te IIOW'ce code to a new languag
 ..
sottwere Maintenance
483 J
[ 482
IF Scoro > c 76 THF.N Grode:= 'A' CASE Score of
• Keep detailed maintenance document.
ELSE IF Scoro > = GO TI IF.N Grnde: = 'B' 76. 100: Grnde: = 'A'
• Use m~sign techniques.
ELS~ IF Score>= 60 THEN Grode: = 'C' GO, 74: Grade: = 'B';

.
---
9.7.1 Source Code Translation
. t ,._.. code to another progromming lnngungc. T he l.nr t
F.LSF: IF Score > = 40 THEN Grode: = 'D' 60, 59: Grade: = 'C';
ELSE IF Grode=·~" 40, 49: Grade: = 'D';
Simplest method 1s to t.rons1a e so.uw . v· . ge-
·on of the oriinnnl lnnjlURge (Bns,c to ,sual 1311s,c) or muv b END
,.. . , e ELSE Grade: = 'F'
l anguagemey be enu pda led ve rsl 1nt ,on m ay be required
a completely different language (FORTRAN to JAVA). Source level trans END
for the following reasons [SOMMOOI: . . Ca) !bl
(i) Hardware pletfonn update: The organization may wish lo chongc standnrd hnrd.
•':8
;are platform. C:omoilers for the original language mny not be nvoi loble on the new Fig. 9.13: Ro:;11uctu11ng o p,og,am

platfonn.
(ii) Staff &kill shortajlel: There may be lack of trained maintena nce staff for t he ori~rinnl
language~ii1ii-a particular problem where programs we re written in some non-
standard language that bu now gone out of general use.
(iii) Organizatiooal polio-chanlff: An orgnniution runy decide _to s~~1dt1rdize on II pur-
ticular lanpage to minimiR ita support software rosl8. Mamt.ammg m ony versions
of old compilen can be very expensive. , , ,. -- •• ~
Tranalat.ion can be done either manually or uaing an autii'tlalion tool. On<' of t he mosL
11
sophisticated t.ools available to uaiat thia proceu is the REFINE ystem lMARK 9 4 I tJ1nt
incorporates powerful pattern matdung and program transfonnal.ion capabilities. It is there-
fore poasible to defme pett.erna in the aourc:e code, which ahould ~ converted. REFlNE recog-
nizes \Jieae and replac:ea them witJi \Jie new construct.a. Althollgh, manual intcrv<'nt.ion is
almOBt alwaya required to tune and improve the general ayatem.
9.7.2 Program Restructuring
Thia involves t.ranaf'ormin( a ayatem &om one repreaent.ational form to another without 8
chanae in the aemuticl or lunc:tiooality. The t.ranaf'ormation would IIIWllly be to a more d esir-
able format.
Due to maintananca adifflill, the programs become complu and difficult to undentand.
To control tbia increue in cnmplui9. the aource code needa to ba l'lllnldured. There are
varioua typea ol ~ lec:lmiqlm and •me are clilcuaaed below:
(i) Control tlow dri.._.....,. I Ille: Thia involvea the impamioD ~a clear control
at.ructure within the 1011n11 CINle and ca be either inter pplglpr f" Wm-modular in
ned•ble ud euiar tp ~ However,
nature. Thia mak• the,...._,
the program may atill aufter, 1nm • Ip, g(modvlpity......,, NlaW oomponenta
of the program may be ....... tlnaala the ciode.
(ii) Effldenc, driwa ~ 'ftaia bmlhea natructurinl a ftandim or •
rithm to make it more efficient.Aaimplammp le ie therepl.....,tofu IP-THEN-
ELSE-IF-ELSE conatnact with a CASI CXlllltnld u lhown in Fig. 9.18. With the
CASE statement, only one boolean variable ie evaluated, wa.., with the IP-THIN·
ELSE-IF-ELSE conat.ruct, more than one olthe boolean apn11ioaa may need to be
teated during uecution thereby makiDc it leaa efficient.
(iii) Adoption-driven r cstructing: T his involves changing \Jie coding style in order to
nd11pl t he program to a new programming language or new operating environment,
for insta nce changing an imperative program in PASCAL into a functional program
in LIS P. Another exnmple is the transformation of a program functions in a sequential
e nvironment to on equivalent but totally different form of processing in a parallel
environment.
9.8 CONFIGURATION MANAGEMENT
Th<' sonwore m ny be considered DB conligurntions of software components. These software
compooenl.8 are released in the fonn of executable code whereea supplier organization keeps
the 110urcc code. This source code is the representation of an executable equivalent, but wh.ich
one? Source code cnn be modified without there being any effect upon executable versions in
uso ond, if strict controls arc nol kcpl, the source code which is the ex:act representation of a
part.iculor cxeculllblc version may no longer exist. The means by which the process of software
de~ .l~ ~n!.Or.!d mnintcnnnce is controlled is called configuration m~a~ment. The configu-
ration monng<'ment is different in development and maintenance phases of life cycle due to
different environments. Softwnrc maintenance is undertaken in the environment of a live
aystem in use by a probnbly large user base. Potential effects upon a live system are much
more immediote tl111n those upon n system still under development. Thus, configuration man-
agement is concerned with the development of procedures and standards for cost effective
managing end contro ll ing changes in an evolving software system.
9.8.1 Co nfiguration Management Activities
'lbe activities are divided into four brood categories [TAKA 96].
1. The iq_eJll.ifjcnt ion of the components and changes.
2. The control of the way by which the changes a re made.
3. Auditing th;changes. -·-·
4. ~ ~ unting-rccording and docuruenlin_![ all the activities that have taken place.
The following documents are required for these nctivities:
• Project plan
• Software requirements specification document

:I
:.I
 softWare Maintenance
Software Engineering 485 ]
484
! CHANGE REQUEST FORM
• Software d esign description document Project ID:
,I
• Source code listing I Change Requester with date:
• Test plans/procedures/test cases
Requested change with date:
• User manuals
All components of the system's configuration are recorded alongwith all relationships Change analyzer:
and dependencies between them. Any change-addition, deletion or modification-mus t be Components affected:
recorded and its effect upon the rest of the system's components should be checked. After a
Associated components:
change has been made, a new configuration is recorded. There is a need to know who is
responsible for every procedure and process along the way and it is a management task both to Estimated change costs:
assign these responsibilities and to conduct audits to see that they are carried out. Change priority:
Change assessment:
9.8.2 Software Versions
Change implementation:
During software maintenance, there will be at least two versions of the software system; the
old version and the new version (s). Since a software system is comprised of software components Date submitted to CCA:
there will also be two or more versions of each component that has been changed. Thus, th~ Date of CCA decision:
software maintenance team has to cope with multiple versions of the software. We can CCA decision:
distinguish between two types of versions namely revisions (replace) and variations (variety).
Change implementer:
Version Control: During the process of software evolution, many objects are produced
for example files, electronic documents, paper documents, source code, executable code and Date submitted to QA:
bitmap graphics. A version control tool is the first stage towards being able to manage multiple Date of implementation:
vei:51ons. O~ce it is in place, a detailed record of every version of the software must be kept. Date submitted to CM:
This com_pnses the QA decision:
• Name of each source code component, including the variations and revisions,
used, Fig. 9.14: Ch;og~ 1equest lom1
• The versions of the various compilers and linkers
1
\ • The name of the software staff who constructed the component.
~ The date and the time at which it was constructed. ~ OCUMENTATION
9.8.3 Change Control Process
I ,,. Software documentation is the written record of facts about a software system recorded with
It will be appropriate if changee t.o IOftware can be predicted. Change control proceea comes the intent to convey purpose, content and clarity. The recording process usually begins when
into effect when the IIOftware and UICICiated documentation are delivered to configuration the need for the system is conceived and continues until the system is no longer in use.
management change request form (as ahown in Fig. 9.14), which should record the recommen- There are different categories of software documentation like user documentation, system
dations regarding the change. The recommendetiODS IIIBY include eaaeument of the proposed documentation, etc.
change, the estimated COits and bow the change lhould be implement.eel. Thie form ia submit-
ted to a Change Conb'ol Authority (CCA), which decidee whether or not the chanp ia t.o be 9.9.1 User Docu m entation
accepted. If change is approved by the CCA, it ia applied t.o the IIOftwue. The reviaed software It refers to those documents, containing descriptions of the functions of a system withou t
is revalidated by the Software Quality Auurance (SQA) team t.o ensure that the change bu reference to how these functions are implemented. A list of user documentation is given in
not adversely affected other parts of the software. The chenged aoftware ia handed over to the Table9.5.
software configuration team and is incorporated in a new venion of the system.

\
 -
r sonware Maintenance
Software Engineering
\ 486 487 J
-,-
,. 1 Docume,
Table 9.5: User documentation ii- ~--~---- - Function

Function System Test Plan Provides description of how program units are tested individually
S. No. DocumrnJ
Provides general description of system's function s a nd how t he whole system is tested after integration
1. System Overview
Acceptance Test Plan
Describe& how to set up the system , customize it to local hard- 6. Describes the tests that the system must pass before usen; accept
2. lnstallation Guide it.
ware needs end configure it to particular hardware and other
software systems. Data Dictionaries
7. Contains description of all terms that relate to the software system
3. Beginner's Guide Provides simple explanations of how to st.art. using the system. in question.

4. Reference Guide Provides in-depth description of each system facility and how it
can be used. This classification and user/system documentation schemes are identical in the sense
that they both include all the information that is contained in software documents.
5. Enhancement Booklet contains a summary of new features.

6. Quick reference card Servers as a factual lookup. ,... -

REFERENCES Ill
7. System administration Provides in~ormation on services such as net-working, security ...
end upgrading.
[ARNO 821 Arnold R.S., "Tl~ Dimensions of Healthy MainU?nance", IEEE Soft.ware Engineering,
1982.
9.9.2 System Documentation
-
[BASI 90] Basili V.R. , "Viewing Software MainU?nance as Reuse--OrienU?d Soflware Development"
IEEE Software, 7, January, 19--25, 1990. '
lt refers to those documentation containing all facets of system, including analysis, specifica-
[BEIZ 90] Beizer B., "Software Testing Techniques", Van Nostrand Reinhold, New York NY, 1990.
tion, design, implementation, t.esting, security, error diagnosis and recovery. System docu-
[BELA 76] Belady L. and Lehman W., "A Model of Large Program Development", IBM Systems
mentation details are given in Table 9.6. J ournal, Vol. 15, No. 3, 225-252, 1976.
[BENN 91] Bennett K et al., "So{lware Maintenance", Butterworth-Heinemann Ltd., Oxford, 1991.
9.9.3 Other Classification Schemes [BIGG 89] BiggerstaffT.J ., "Design Recovery for MainU?nance and Reuse•, Computer, 22(7), July,
There are other ways in which documentation may be classified. There may be three levels of 36-49, 1989.
documentation: user manuals, operator's manuals and maintenance manuals. User manual [BOEH 81] Boehm B.W., "So{lware Engineering Economics", Prentice Hall, Englewood Cliffs, New
J ersey, 1981.
deacribes what the system does without necessarily going into the details of how it does it or
how to get the system to do it. The operator's manual deecribes how to use the system as well [BOEH 83] Boehm B.W., "The Economic of So{lware MainU?nance", Proc. Workshop on Software
as giving instructions on how to recover from faults. The maintenance manual contains details Maintenance", Silver Spring, MD, IEEE Computer Society Press, 9-37, 1983.
[BOT!' 94] Bot taci L. and Jones J .G., "Formal Specification on Using Z: A Modeling Approach",
of the functional specification, design, code listing, test data and results. Int. Thomson Publishing, London, 1994.
Tabla I.I: System docu~tion [BROO 87] Brooks R., "No Silver Bullet-Essence and Accidents of Soflware Engineering", IEEE
Computer, 20 (4), 10-20, 1987.
S. No. 0--., Function 't [ClDK 90] Chikofsky E.J. and Cross Jr. J .H., "Reverse Engineering and Design Recovery: A Tax-
onomy", IEEE Software, 7, January, 13-17, 1990.
l. 8yal8D Rationale Deacrii- the objedivee of the entire lystem.
[COLLO 78] Collofello J .S. et al.,"Ripple Effect Analysis of So{lware Ma intenance", Proc. COMPSAC
2. SRS Provide& illf'-.tion on exact requirementa of system u agreed 78, 60-65, 1978.
~ - and dneloper [GILLI 90] Gillis KD. and Wright D.G., "Improving Software Maintenance using System Level
3. Specificatioa/Deaip Reverse Engineering", In Proc. lEEE Conference on Software Maintenance", 84-90,
Providell clelc:ription of: LA, IEEE Computer Society Press, 1990.
(i) How syatem requiJ-.ta are implement.eel.
[LAMB 88] Lamb D.A, "Software Engineering: Planning for Change", Prentice Hall, Englewood
(ii) How the 1yltem ia demmpoaecl into a aet of interacting pro- Cliffs, NJ, 1988.
p-amunita. IJ,EHM86] I:.ehman M .M ., "Program Evolution", Academic Press. London, 1985.
(iii) Tbe function of eech Jll'OlrUl mm. [LIEN 80] Lient z B.P . and Swanson E.B., "Soflware Maintenance Management", Addison-Wesley
4. Implementation Providell deacription of: Publishing Company, Reading, Massachusetts, 1980.
(il How the detailed 8)'ltem cle■ign ia upre■aed in 10me formal Morkosian L. et al. "Using an Enabling Technology to Reengineer Legacy Systems",
programming language. Communications of the ACM, 34(5), 58-70, May, 1994.
Muller H.A. et al., "A Reverse E11gineering Environment Based on Spital and Visu~
(ii) Program actions in the form of intra program comments.
Software Interconnection Models", Software Engineering Notes, 17(5), Dec, 34, 88-9 •
(Contd.)... 1992.
 .... " 1111111

Software Englnee~
1488 489]
fROTH 96] Rolhennel G. and Harrold M.J ., "Analyzing Regression Test S election Tech11iques", IEEE (c) modification in son.wore due to increase in complexity
Transactions on Software Engineering 22 (8), 629-551, August 1996.
(d ) modification in software to match changes in the ever-changing environment.
fROTH 96 a] Rotbennel R., "Efficient Effective Regression Testing Using Safe Test Selection
7 Perfective maintenance refers to enhancements
Techniques", Ph. D Thesis, Clem.son University, May. 1996. 9
• • (a) making the product better
fRLlGA 901 Rugaber S. et al., "Recogniwig Design Decisions in Programs," fEEE Software, 7(1),
January, 46-54, 1990. (bl making the product faster and smaller
fRUGA 94] Rugober S., "While Paper on Rct>erse Engineering", Tech Report, Georgia Institute of (c) making the product with new functionalities
Technology, Moreb. 1994. (d) all of the above.
(SAGE 90] Sage A. and Palmer J .D., "Software System.s Engin«ring", John Wiley and Sons, 1990.
9,8. As per distribution of maintenance effort, which type of maintenance has consumed maximum
(SOMM 001 Sommerville lao, "Software Enginttring", Addison- Wesley, 2000. share?
(STEP 78] Stephen S.Y. et al., "Ripple Effect Analysis of Software Maintenance", in Proc. (a) adaptive
COMPSAC78, 1978. (b) corrective
(c) perfective (d) preventive.
(STEP 80] Stephen S .Y. and Collofello J .S., "Some Stability MeCU1ures for Soflware Maintenance"
IEEE Software Engg., 1980. ' 9,9, As per distribution of maintenance effort, which type of maintenance bas consumed minimum
[STEP 801 Stephen S.Y. and Callofello J .S .• "So~ Stability MeCU1ures for Software Maintenan ce" share?
IEEE Trans on Software Engineering, 28--35, 1980. ' (a) adaptive (b) corrective
(STRI 82] Strickland J .P. et al., "An EL'Ofoing System", IBM Systems Journal, 21 (4), 490--613 (c) perfective (d) preventive.
1982. '
9.10. Which one is not a maintenance model?
[TAKA 961 Takang A.A., Grubb PA, "Software Mainunance", Thomson Computer Press, U.K
(a) CMM (b) iterative Enhancement model
[TAlIT 83] Taute B.J., "Quality Assuran« and Maintenance Application Systems", Proc. of the
(c) quick-fix model (d) reuse-oriented model.
National AFIPS computer conference, PP 123-129, 183.
[ZVEG 95] Zvegintzov N .. "Software Ma~,v,u Tttlanology Reference Guide: 1994 / 95 European 9.11. In which model, fixes are done without detailed aoalysis of the long-term effects?
Ed.ttion", Software Maintenance News, Inc., Los Alamitos, California, 1995. (a) reuse oriented model (b) quick-fix model
(c) toute maintena.nce model (d ) none of the above.
9.12, Iterative enhancement model is a
MULTIPLE CHQ~E QUESTIONS (a) three stage model (b) two stage model
Note:: ChOOSt' most appropriatt answer of 1M followUIII quutions: (c) four stage model (d) seven stage model.
9.1. Process of generating analysis and design documents ia called 9.13, Taute maintenance model has
(o) inverae Engineering (b) software Engineering (a) two phases (b) six phases
(c) revene Encineering (d) re-engineering. (c) eight phases (d) ten phases.

I.I. Regreaaion testing ia primarily related to
(a) functional tMting
(cl development c.tina
t.a. Which one ia not a c:atepry of maint.eoance 7
(a) conec:tive maint.eoance
(cl adaptive maintenaDoe
1.4. The maintenance initiated by defect.a in the IIOftware ia called
(al corrective maint.eoance
(cl perfective maintenance
9.6. Patch iJ known u
(a J emergency fIIea
(cl critical 6xea
9.6. Adapti•e maintenance iJ related to
(a) modification in aaftware due to failwu
(bJ modification in aoftware due to demand of new functionalitiea
9.14. In Boehm model, ACT stands for
I.
(b) data !low I.eating f (a) actual change time (b) actual change traffic
(d) maintenance testing. (c) annual change traffic (d) annual change time.
I
9.11. Regression testing i.s known ae
(b) efl'ective maintenance (a) the process of retesting the modified parts of the software
(cf) perfective maintenance. (b) the process of testing the design documents
(c) the process of reviewing the SRS
(b) adaplive maintenance (d) none of the above.
(d) preventive maintenance. 1.11. The purpose of regression testing is to
i. (a) increase confidence in the correctness of the modified progrnm
(b) routine fiua (b) locate errors in the modified program
(d) 111111e of the above. (c) preaerve the quality and reliability of software
(d) all of the above.
1.17. Regreaaion testing is related to
(a) maintenance of software (b) development of software
(c) both (a) and (b). (d) none of the above.
 T

Software Engineering ~·;""""" ,,, J

[ 490

clesiterative
9.12, How enhancement model is helpful during maintenance? Explain the vanoas stage
of this model.
9.18. Which one is not a selective retest technique I.
(bl minimization technique
(al cover age technique :xplain the Boehm's maintenance model with the help of a diagram.
(dl maximization technique.
(cl safe technique 4 State the various steps of reuse oriented model. ls it a recommended model in object oriented
9,JS,
e.1 • design? .
9.19. Purpose of reverse engineering is to
(a) recover information from the existing code or any other intermediate document
Describe the Taute ma mtenance model. What are Various phases of this model?
(b) redocumentation and/or document generation 6 Write a short note on Belady a nd Lehman model for the calculation of maintenance effort.
9.lli,
(cl understand the source code and associated documents 9.1 7· 0escn·be various maintenance cost estimation models ·
(d) all of the abo,•e. 9.1 · The development effort fo~ a project is 600 PMs. The empirically determined constant (I{) of
9.20. Legacy systems are 1
9,18. dy and Lehman model IS 0.6. The complexity of code is quite high and is equal to 7. Calculate
(b ) new systems the
(a) old syste.ms Be atotal effort expended CM) if maintenance team has resonable level of understanding of the
k) undeveloped systems (dl none of the above. oject (d = 0.7).
9.21. User documentation consists of pr ual change traffic (ACT) in a software system is 25% per year. The initial develpment cost
(a ) system oven<iew
(b ) installation guide
(d) all of t h e above. 9,19- was
Ann Rs · 20 laca. Total life time for software is 10 years. what is the total cost of the software
(C') reference guide te
9.22. Which one is not a user documentation? sya IIl? ·
nn DiJii t· te bet
~ . dd I .
(a ) beginner's Guide (b) installation guide What is r egression tes 1;, eren 1a ween regression an eve opment testing.
(c) SRS (d) system administration . 9JO. What is the importance of regression test selection? Discuss with the help of eumples.
9.23. System documentation may not have 9Jl. What are selective r etest techniques? How are they different from "retest-all" technique?
(a ) SRS (b ) design document 9,22. lain the various categories of retest techniques. Which one is not useful and why?
(C') acceptance Test Plan (d) system administration.
~- Exp
99.23, . categories to evaluate regression test selection techniques? Why do we use such
Wha t are the
9.24. The process by which existing processes and methods are replaced by new techniques is : categorisation?
(a) reverse engineering (bl business process re-engineering
9.25. What is reverse engineerin(l Discuss levels of reverse engineering.
(c) soft.ware configuration management (d) technical feasibility.
9.26. What are the appropriate reverse engineeing tools? Discuss any two tools in detail.
9.25. The process of transforming a model into source code is 9.27. Discuss reverse engineering and re-engineering.
(a ) reverse engineering (b) forward engineering
9.28. What is re-enginee.r ing? Differentiate between re-engineering and new development.
(c) re-engineering (d) restructuring.
9.29. Discuss the suggestions that may be useful for the modification of the legacy code.
9.30. Explain various types of restructuring techniques. How does restructuring help in maintaining
a program?
EXERCISE
9.31. Explain why single entry, single exit modules make testing easier during maintenance.
9.1. What ia aol\ware maintenance? Describe various cetcgories of maintenance. Which category 9.32. What are configuration management activities? Draw the perfonna of change request form.
consumes muimum effort and why? 9.33. Explain why the success of a system depends heavily on the quality of the documentation gener-
9.2. What are the implications of maintenance for a one person software production organization? ated during system development.
9.3. Some people feel that "maintenance ia manageable". What is your opinion about this issue? 9.34. What is an appropriate set of tools and documents required to maintain large software product?
9 .4. Diacuaa various problems during maintenance. Describe some solutions to these problems. 9.35. Explain why a high degree of coupling among modules can make maintenance very difficult?
9.6. Why do you think that the mistake ia frequently made of considering software maintenance 9.36. Is it feasible to specify maintainbility in the SRS? If yes, how would we specify it?
inferior to aol\ware development? 9.37. What tools and techniques are available for software maintenance? Discuss any two of them.
9.6. Explain the importance of maintenance. Which category consumes maximum effort and why? 9.38. Why is maintenance programming becoming more challenging than new development? What
9.7. Explain the at.epa of eoft.ware maintenance with help of a diagram. are desirable characte.ristics of a maintenance programmer ?
9.8. What is aelf deacript.iveneaa of a program? Explain the effect of this parameter on maintenance 9.39. Why little attentiol\ is paid to maintainability during design phase?
activities. 9.40. List out system documentation and also eltJ)lain their purpose.
9.9. What ia ripple effect? Diecuaa the various aspects of ripple effect and how does it affect the
stability of a program?
9.10. What ia maintainability? What is its role during maintena nce?
9.11. Describe quick-fix model. What are the advantages and disadvantages of this model?
l .