Transcript Software change - University of St Andrews

Software evolution 2
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 21
Slide 1
Evolution processes

Evolution processes depend on
•
•
•

The type of software being maintained;
The development processes used;
The skills and experience of the people
involved.
Proposals for change are the driver for
system evolution. Change identification and
evolution continue throughout the system
lifetime.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 21
Slide 2
Change identification and evolution
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 21
Slide 3
The system evolution process
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 21
Slide 4
Change implementation
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 21
Slide 5
Urgent change requests

Urgent changes may have to be
implemented without going through all
stages of the software engineering process
•
•
•
If a serious system fault has to be repaired;
If changes to the system’s environment (e.g. an
OS upgrade) have unexpected effects;
If there are business changes that require a
very rapid response (e.g. the release of a
competing product).
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 21
Slide 6
System re-engineering



Re-structuring or re-writing part or all of a
legacy system without changing its
functionality.
Applicable where some but not all sub-systems
of a larger system require frequent
maintenance.
Re-engineering involves adding effort to make
them easier to maintain. The system may be restructured and re-documented.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 21
Slide 7
Advantages of reengineering

Reduced risk
•

There is a high risk in new software
development. There may be development
problems, staffing problems and specification
problems.
Reduced cost
•
The cost of re-engineering is often significantly
less than the costs of developing new software.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 21
Slide 8
Forward and re-engineering
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 21
Slide 9
The re-engineering process
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 21
Slide 10
Reengineering process activities

Source code translation
•

Reverse engineering
•

Restructure automatically for understandability;
Program modularisation
•

Analyse the program to understand it;
Program structure improvement
•

Convert code to a new language.
Reorganise the program structure;
Data reengineering
•
Clean-up and restructure system data.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 21
Slide 11
Re-engineering approaches
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 21
Slide 12
Reengineering cost factors




The quality of the software to be
reengineered.
The tool support available for reengineering.
The extent of the data conversion which is
required.
The availability of expert staff for
reengineering.
•
This can be a problem with old systems based
on technology that is no longer widely used.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 21
Slide 13
Legacy system evolution

Organisations that rely on legacy systems must
choose a strategy for evolving these systems
•
•
•
•

Scrap the system completely and modify business
processes so that it is no longer required;
Continue maintaining the system;
Transform the system by re-engineering to improve its
maintainability;
Replace the system with a new system.
The strategy chosen should depend on the system
quality and its business value.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 21
Slide 14
System quality and business value
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 21
Slide 15
Legacy system categories

Low quality, low business value
•

Low-quality, high-business value
•

These make an important business contribution but are
expensive to maintain. Should be re-engineered or
replaced if a suitable system is available.
High-quality, low-business value
•

These systems should be scrapped.
Replace with COTS, scrap completely or maintain.
High-quality, high business value
•
Continue in operation using normal system maintenance.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 21
Slide 16
Business value assessment

Assessment should take different viewpoints
into account
•
•
•
•
•

System end-users;
Business customers;
Line managers;
IT managers;
Senior managers.
Interview different stakeholders and collate
results.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 21
Slide 17
System quality assessment

Business process assessment
•

Environment assessment
•

How well does the business process support
the current goals of the business?
How effective is the system’s environment and
how expensive is it to maintain?
Application assessment
•
What is the quality of the application software
system?
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 21
Slide 18
Business process assessment

Use a viewpoint-oriented approach and seek
answers from system stakeholders
•
•
•
•
•

Is there a defined process model and is it followed?
Do different parts of the organisation use different
processes for the same function?
How has the process been adapted?
What are the relationships with other business processes
and are these necessary?
Is the process effectively supported by the legacy
application software?
Example - a travel ordering system may have a low
business value because of the widespread use of
web-based ordering.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 21
Slide 19
Environment assessment 1
F acto r
Qu esti on s
S upp li er
sta bi lit y
Is t he supp lie r is still in ex istenc e ? Is t he supp li er fi nanc iall y
sta bl e and li ke ly to con ti nue in ex istenc e ? If t he supp li er is
no long e r in bu sin e ss, does so m eone els e m aintain t he
sy st em s?
F ail ur e rate
Doe s the ha rdwa re h a ve a high rate of r epor ted f ail ure s?
Doe s the suppo rt sof tw a re c rash and fo rce sy st em resta rts ?
Age
How old is t he hardw a re and so ft wa re? The olde r the
ha rdwa re a nd suppor t so ft wa re, t he m ore obso lete it w ill b e .
It m ay still func ti on co rr ec tl y bu t t he re cou ld be sign ific an t
econo mi c and bus ine ss bene fits t o m oving t o m o re mod e rn
sy st em s.
P erfo rm ance
Is t he pe rf or m an c e o f the sy st em a dequa te? Do p e rform a nce
prob lem s have a si gni fi can t effe c t on sys tem us e rs?
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 21
Slide 20
Environment assessment 2
S uppor t
requ ire m e nts
Wha t l oca l suppo rt i s re qu ired by the ha rdwa re a nd
so ft wa re? If ther e a re high co st s a ssoc iated w ith t h is suppo rt ,
it m ay be wor th cons ide ri ng sys tem r ep lace m en t.
M ai nt e nance
co st s
Wha t are the co sts of hardw a re m aintenanc e and suppo rt
so ft wa re l ic ence s? O lde r ha rdwar e m ay have higher
m aintenanc e co st s t han m ode rn sys tems . S uppor t so ft wa re
m ay have h igh annua l l ic ens ing cos ts .
Interop e rab ilit y
A re the re p robl em s interf ac ing th e sys tem to othe r sys tem s?
C a n co m pil ers etc. be used w it h cu rr en t ve rs ion s o f th e
ope rati ng sys tem ? I s hardw a re e m ulati on requ ir ed?
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 21
Slide 21
Application assessment 1
F acto r
Qu esti on s
Unde rstand a bilit y
How diffi cu lt is it to unde rstand t he sour c e cod e o f the
cu rre nt sys tem ? How c omp le x a re th e con tr ol st ruc tures
tha t a re us e d? Do va ri ab les have m ean ing ful na m es tha t
ref le ct the ir func ti on?
Docu m en tati on
Wha t sy st em docu m en ta tion i s ava il ab le? Is t he
docu m en tati on co m plete, con sist en t a nd up -to-da te ?
Da ta
Is t he re an exp li cit da ta m od e l for t he sys tem ? To wha t
ex ten t i s da ta dup li ca te d in d iff er e nt fi le s? I s the da ta used
by th e sys tem up -to-da te a nd con si sten t?
P erfo rm ance
Is t he pe rf or m an c e of the app li ca ti on adequa te? Do
pe rfo rm anc e p rob lem s have a si gn ifican t effe ct on sy ste m
us e rs?
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 21
Slide 22
Application assessment 2
P rog rammi ng
language
A re m od e rn co m p il er s a va il ab le for the prog rammi ng
language us e d to deve lop the sy st em ? Is the prog rammi ng
language still u sed fo r n e w sys tem deve lop m en t?
Con fi gu rati on
m anage me nt
A re al l ve rsion s o f a ll pa rts o f th e sys tem m a naged by a
con fi gur a tion m anage m en t sy st em ? Is t he re a n exp li cit
de scr ipti on of t he v e rsi ons of co m ponen ts t ha t a re used i n
the cur ren t sy stem ?
T es t da ta
Doe s test da ta f or t he sys tem ex ist? I s the re a re c ord of
regr e ssion tests c ar ri ed ou t when new fe at ure s h a ve be e n
added t o the sy st em ?
P ersonne l sk ill s
A re the re peop le ava il ab le who hav e the sk ill s t o m aintain
the app li ca ti on? A re the re on ly a limit ed numb e r of peop le
who under st and the sys tem ?
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 21
Slide 23
Key points



The process of evolution is driven by requests
for changes from system stakeholders.
Software re-engineering is concerned with restructuring and re-documenting software to
make it easier to change.
The business value of a legacy system and its
quality should determine the evolution strategy
that is used.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 21
Slide 24