Software change 

q

Managing the processes of  software system change 

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 27

Slide 1

Objectives
q

To explain different strategies for changing  software systems
• • • Software maintenance Architectural evolution Software re­engineering

q q

To explain the principles of software maintenance To describe the transformation of legacy systems  from centralised to distributed architectures

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 27

Slide 2

Topics covered
q q q

Program evolution dynamics Software maintenance Architectural evolution

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 27

Slide 3

Software change
q

Software change is inevitable
• • • • • New requirements emerge when the software is used The business environment changes Errors must be repaired New equipment must be accommodated The performance or reliability may have to be improved

q

A key problem for organisations is implementing  and managing change to their legacy systems

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 27

Slide 4

Software change strategies
q

Software maintenance
• Changes are made in response to changed requirements but the  fundamental software structure is stable The architecture of the system is modified generally from a  centralised architecture to a distributed architecture No new functionality is added to the system but it is  restructured and reorganised to facilitate future changes

q

Architectural transformation

q

Software re­engineering

q

These strategies may be applied separately or  together
Software Engineering, 6th edition. Chapter 27 Slide 5

©Ian Sommerville 2000 

Program evolution dynamics
q

q

q

Program evolution dynamics is the study of the  processes of system change After major empirical study, Lehman and Belady  proposed that there were a number of ‘laws’  which applied to all systems as they evolved There are sensible observations rather than laws.  They are applicable to large systems developed  by large organisations. Perhaps less applicable in  other cases
Software Engineering, 6th edition. Chapter 27 Slide 6

©Ian Sommerville 2000 

Lehman’s laws
Law Continuing change Description A program that  is used in a real­world environment necessarily must change or become progressively less useful in that environment. Increasing complexity As an evolving program  changes, its structure tends to become more complex. Extra resources  must be devoted to preserving and simplifying the structure. Large program evolution Program evolution is a self­regulating  process. System attributes  such as size, time between releases and the  number of reported errors are approximately invariant for each system release. Organisational stability Over a programÕs lifetime, its rate of development is approximately constant  and independent of the resources devoted to system development. Conservation  of Over the lifetime of a system, the incremental change familiarity in each release is approximately constant.
©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 27 Slide 7

Applicability of Lehman’s laws
q q

q

This has not yet been established They are generally applicable to large, tailored  systems developed by large organisations It is not clear how they should be modified for
• • • • Shrink­wrapped software products Systems that incorporate a significant number of COTS  components Small organisations Medium sized systems

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 27

Slide 8

Software maintenance
q

q

q

Modifying a program after it has been put into  use Maintenance does not normally involve major  changes to the system’s architecture Changes are implemented by modifying existing  components and adding new components to the  system

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 27

Slide 9

Maintenance is inevitable
q

q

q

The system requirements are likely to change  while the system is being developed because  the environment is changing. Therefore a  delivered system won't meet its requirements! Systems are tightly coupled with their  environment. When a system is installed in an  environment it changes that environment and  therefore changes the system requirements. Systems MUST be maintained therefore if they  are to remain useful in an environment
Software Engineering, 6th edition. Chapter 27 Slide 10

©Ian Sommerville 2000 

Types of maintenance
q

Maintenance to repair software faults
• Changing a system to correct deficiencies in the way meets  its requirements

q

Maintenance to adapt software to a different  operating environment
• Changing a system so that it operates in a different environment  (computer, OS, etc.) from its initial implementation

q

Maintenance to add to or modify the system’s  functionality
• Modifying the system to satisfy new requirements

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 27

Slide 11

Distribution of maintenance effort

FF aral uu led tpn  ) c r tn aia io (m 1o 7 fi %r y S () o6 fe 5 ti % w  t ao r n an d p o () 1 8 %
Software Engineering, 6th edition. Chapter 27

©Ian Sommerville 2000 

Slide 12

Spiral maintenance model

n SSIm pem enp c aln iare fo t t1 i it o RV ea ls ltn a ii sd Oa p  o ra a te i3 o n R e l2
Software Engineering, 6th edition. Chapter 27 Slide 13

©Ian Sommerville 2000 

Maintenance costs
q

q

q

q

Usually greater than development costs (2* to  100* depending on the application) Affected by both technical and non­technical  factors Increases as software is maintained.  Maintenance corrupts the software structure so  makes further maintenance more difficult. Ageing software can have high support costs  (e.g. old languages, compilers etc.)
Software Engineering, 6th edition. Chapter 27 Slide 14

©Ian Sommerville 2000 

S51234$ y05555 s012345 t  00000 e 0000 m 1 Se M ymae sot ia tvc no en tn m es  lts c 2o  t D e  p
Development/maintenance costs
©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 27 Slide 15

Maintenance cost factors
q

Team stability
• Maintenance costs are reduced if the same staff are involved with  them for some time The developers of a system may have no contractual responsibility  for maintenance so there is no incentive to design for future change Maintenance staff are often inexperienced and have limited domain  knowledge As programs age, their structure is degraded and they become  harder to understand and change
Software Engineering, 6th edition. Chapter 27 Slide 16

q

Contractual responsibility

q

Staff skills

q

Program age and structure

©Ian Sommerville 2000 

Evolutionary software
q

Rather than think of separate development and  maintenance phases, evolutionary software is  software that is designed so that it can  continuously evolve throughout its lifetime

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 27

Slide 17

The maintenance process

CP SeiC S h e ysm rm a a sl pny n Ic p la l g rvAC s e n t v e t me o a p lr me ad h t a rv me en ac g e rs mmm e a iicai q ili n ito un nn t fe a t ye a spi gn ct c t i e i n e a n c
Software Engineering, 6th edition. Chapter 27 Slide 18

©Ian Sommerville 2000 

Change requests
q

q

q

Change requests are requests for system changes  from users, customers or management In principle, all change requests should be  carefully analysed as part of the maintenance  process and then implemented In practice, some change requests must be  implemented urgently
• • • Fault repair Changes to the system’s environment Urgently required business changes
Software Engineering, 6th edition. Chapter 27 Slide 19

©Ian Sommerville 2000 

Change implementation

P RR dt re enenen oqqS p at u v supo d n d fe is ig la rs rt tr eaw me p mm s c li t hy a n g
Software Engineering, 6th edition. Chapter 27 Slide 20

©Ian Sommerville 2000 

Emergency repair

CszsieD h o Mvd a Au ed n u ryly g n o iri e re c sf a e ee ld d  o y  d m ft rs c o e  qo u t
Software Engineering, 6th edition. Chapter 27 Slide 21

©Ian Sommerville 2000 

Maintenance prediction
q

Maintenance prediction is concerned with  assessing which parts of the system may cause  problems and have high maintenance costs
• • • Change acceptance depends on the maintainability of the  components affected by the change Implementing changes degrades the system and reduces its  maintainability Maintenance costs depend on the number of changes and costs  of change depend on maintainability

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 27

Slide 22

Maintenance prediction

W hh an  ae p? tfs se  n oi m wp itrt n lea biy ht es m x v W mo htsa iib ahr n tefd ey  a t y tn p? a rq t sa o me ag W ory P itibm s bb rtl ht fe lnc d ah itfm c  let ke i w le y cu m i h g  m e iblh no ess ai nf ce s o in tnt c  lem gw PtmW rt erteme eya ht a dm oy inP as? c e iig  gn nio sd ve a eh h o rx a s hr e c  so c H oh w  pe m ag n y  ? c a n y rsb ed q u e t ? x e
Software Engineering, 6th edition. Chapter 27 Slide 23

©Ian Sommerville 2000 

Change prediction
q

q

q

Predicting the number of changes requires and  understanding of the relationships between a  system and its environment Tightly coupled systems require changes  whenever the environment is changed Factors influencing this relationship are
• • • Number and complexity of system interfaces Number of inherently volatile system requirements The business processes where the system is used

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 27

Slide 24

Complexity metrics
q

q

q

Predictions of maintainability can be made by  assessing the complexity of system components Studies have shown that most maintenance effort  is spent on a relatively small number of system  components Complexity depends on
• • • Complexity of control structures Complexity of data structures Procedure and module size 

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 27

Slide 25

Process metrics
q

Process measurements may be used to assess  maintainability
• • • • Number of requests for corrective maintenance Average time required for impact analysis Average time taken to implement a change request Number of outstanding change requests

q

If any or all of these is increasing, this may  indicate a decline in maintainability

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 27

Slide 26

Architectural evolution
q

q

There is a need to convert many legacy systems  from a centralised architecture to a client­server  architecture Change drivers
• • • Hardware costs. Servers are cheaper than mainframes User interface expectations. Users expect graphical user  interfaces Distributed access to systems. Users wish to access the system  from different, geographically separated, computers

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 27

Slide 27

Distribution factors
Factor Business importance Description Returns on the investment of distributing a legacy system depend on its importance to the business and how long it will remain important. If distribution provides more efficient support for stable business processes then it is more likely to be a cost­effective evolution strategy. The older the system the more difficult it will be to modify its architecture because previous changes will have degraded the structure of the system. The more modular the system, the easier it will be to change the architecture. If the application logic, the data management and the user interface of the system are closely intertwined, it will be difficult to separate functions for migration. Application distribution may be necessary if there is company policy to replace expensive mainframe computers with cheaper servers. .
Software Engineering, 6th edition. Chapter 27 Slide 28

System age System structure

Hardware procurement policies
©Ian Sommerville 2000 

Legacy system structure
q

q

Ideally, for distribution, there should be a clear  separation between the user interface, the system  services and the system data management In practice, these are usually intermingled in older  legacy systems

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 27

Slide 29

Legacy system structures

U sr ec rc  tf ie n a e S e rs v i e D atu tat bi so en I or d rb eld afs ld m e o i

U sc ec rr  v ie n tf e a e S e rs ie D ats ta b s Rm ey a e lg  a e c s
Slide 30

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 27

Layered distribution model

Pr rtss en sti n a iv o D ao ttd  o ve le Icc nn eo rn ia  l c A p lb a D
Slide 31

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 27

Legacy system distribution

D nc e ltult sC ii keian t cg osp pr a Po i n L Me et ila rr g dy) a ee c w y rrp  e ea s  ( m lw A a p la if c a tn o ss L e et ri g v am e c D y a  e tr s b U sm ec re  ril i n ns e Ca h a r c t e
Software Engineering, 6th edition. Chapter 27 Slide 32

©Ian Sommerville 2000 

Distribution options
q

q

q

The more that is distributed from the server to the  client, the higher the costs of architectural  evolution The simplest distribution model is UI distribution  where only the user interface is implemented on  the server The most complex option is where the server  simply provides data management and application  services are implemented on the client
Software Engineering, 6th edition. Chapter 27 Slide 33

©Ian Sommerville 2000 

Distribution option spectrum

SanSb Sn eeitlCi Ci rIvoers esn verltS lta :a  rP rP noi:ra i:rs t ta eio eb rd vtn vto c n ne ic :e :e o  a  ta nDD v a c e D Ictl Ictl ln nr nr t e o t o ta c S DD s ac atn ta tn  li b sa v Ci  ltnIato ltrto v ns i:e d ce en i rio n oS  s d P ea a sd r n g   c  r e f
Software Engineering, 6th edition. Chapter 27 Slide 34

©Ian Sommerville 2000 

User interface distribution
q

q

q

UI distribution takes advantage of the local  processing power on PCs to implement a  graphical user interface Where there is a clear separation between the UI  and the application then the legacy system can be  modified to distribute the UI Otherwise, screen management middleware can  translate text interfaces to graphical interfaces

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 27

Slide 35

User interface distribution

D i ent silth kfw t C oc ps P  r c i e n SioG cn U rdn Ia eg t nn  es st c r p t L Sr eo cw g rm a ee c n y ia  f  lm s d t e e m A p lr ii c a te n ss e rc v e D a ta b U s e r  e i n
Software Engineering, 6th edition. Chapter 27 Slide 36

©Ian Sommerville 2000 

UI migration strategies

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 27

Slide 37

Key points
q

q

q

Software change strategies include software  maintenance, architectural evolution and software  re­engineering Lehman’s Laws are invariant relationships that  affect the evolution of a software system Maintenance types are
• • • Maintenance for repair Maintenance for a new operating environment Maintenance to implement new requirements

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 27

Slide 38

Key points
q q

q

q

The costs of software change usually exceed the  costs of software development Factors influencing maintenance costs include staff  stability, the nature of the development contract,  skill shortages and degraded system structure Architectural evolution is concerned with evolving  centralised to distributed architectures A distributed user interface can be supported using  screen management middleware
Software Engineering, 6th edition. Chapter 27 Slide 39

©Ian Sommerville 2000 

Sign up to vote on this title
UsefulNot useful