1. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 1 Software change l Managing the processes of software system change

2. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 2 Objectives l To explain different strategies for changing software systems Software maintenance Architectural evolution Software re-engineering l To explain the principles of software maintenance l To describe the transformation of legacy systems from centralised to distributed architectures

3. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 3 Topics covered l 27.1 Program evolution dynamics l 27.2 Software maintenance l 27.3 Architectural evolution

4. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 4 Software change l 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 l A key problem for organisations is implementing and managing change to their legacy systems

5. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 5 Software change strategies l Software maintenance l Architectural transformation l Software re-engineering l These strategies may be applied separately or together l Alternative – complete replacement from scratch

6. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 6 l Study of the processes of system change l Lehman and Belady proposed ‘laws’ concerning the evolution of systems l They are applicable to large systems developed by large organizations. Program evolution dynamics

7. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 7 Lehman’s laws

8. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 8 Lehman’s First Law l Continuing Change Environment changes New requirements l Not controversial

9. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 9 Lehman’s Second Law l Increasing Complexity l To combat this takes effort l Such extra effort is rarely done l Not controversial

10. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 10 Lehman’s Third Law l Large Program Evolution l System attributes (size, time between releases, error rates) are invariant from release to release l Determined by organizational practices and system structure l Is controversial

11. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 11 Lehman’s Fourth Law l Organization Stability l Rate of development approximately constant l Determined by organizational practices and system structure l Is controversial

12. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 12 Lehman’s Fifth Law l Conservation of familiarity l Over lifetime of system, incremental change in each release is approximately constant

13. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 13 Applicability of Lehman’s laws l This has not yet been established l They are generally applicable to large, tailored systems developed by large organisations l 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

14. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 14 l Modifying a program after it has been put into use l Maintenance does not normally involve major changes to the system’s architecture l Changes are implemented by modifying existing components and adding new components to the system 27.2 Software maintenance

15. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 15 l The system requirements are likely to change l When a system is installed it changes the environment and therefore changes the system requirements. l Systems MUST be maintained therefore if they are to remain useful in an environment Maintenance is inevitable

16. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 16 l Repair software faults l Adapt software to a different operating environment l Add to or modify the system’s functionality Types of maintenance

17. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 17 Distribution of maintenance effort

18. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 18 Spiral maintenance model

19. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 19 l Usually greater than development costs l Affected by both technical and non-technical factors l Increases as software is maintained. l Ageing software can have high support costs Maintenance costs

20. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 20 Development/maintenance costs

21. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 21 l Team stability l Contractual responsibility l Staff skills l Program age and structure Maintenance cost factors

22. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 22 Evolutionary software l 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

23. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 23 The maintenance process

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

25. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 25 Change implementation Emergency repair

26. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 26 Emergency repair

27. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 27 Maintenance prediction l Change acceptance affected by the maintainability of the components affected by the change l Maintenance prediction is concerned with assessing which parts of the system may cause problems and have high maintenance costs

28. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 28 Maintenance prediction

29. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 29 Change prediction l Requires an understanding of the relationships between a system and its environment l Tightly coupled systems require changes whenever the environment is changed l 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

30. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 30 Maintainability Prediction l Most maintenance effort on small number components l Prediction of maintainability based on complexity l Complexity metrics Complexity of control structures Complexity of data structures Procedure and module size l It may be beneficial to replace complex components

31. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 31 Maintainability Prediction via Process metrics l 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 l If any or all of these are increasing, this may indicate a decline in maintainability

32. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 32 Architectural evolution l The architecture of the system is modified. l There is a need to convert many legacy systems from a centralized architecture to a client-server architecture l Change “drivers” Hardware costs. User interface expectations. Distributed access to systems.

33. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 33 Distribution factors

34. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 34 Distribution factors FactorDescription Business importanceReturns on the investment System ageOlder systems harder to modify System StructureModularity aids change Hardware Procurement Policies Replacement of mainframes suggests change

35. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 35 Legacy system structure l Ideally, for distribution, there should be a clear separation between the user interface, the system services and the system data management l In practice, these are usually intermingled in older legacy systems

36. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 36 Legacy system structures Database User interface Services Database User interface Services Ideal model for distribution Real Legacy Systems

37. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 37 Legacy system structures

38. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 38 Legacy system distribution

39. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 39 Layered distribution model

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

41. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 41 Distribution option spectrum

42. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 42 User interface distribution l UI distribution takes advantage of the local processing power on PCs to implement a graphical user interface l Where there is a clear separation between the UI and the application then the legacy system can be modified to distribute the UI l Otherwise, screen management middleware can translate text interfaces to graphical interfaces

43. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 43 User interface distribution

44. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 44 UI Migration Strategies StrategyAdvantagesDisadvantages Using window management system l Flexible UI Design l Better UI Performance l Platform dependent l Interface consistency Using WWW browser l Platform independent l Lower Training Costs l Browser Availability l Easier Interface Consistency l Poorer UI Performance l Interface design constrained by browsers

45. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 45 UI migration strategies

46. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 46 Key points l Software change strategies include software maintenance, architectural evolution and software re-engineering l Lehman’s Laws are invariant relationships that affect the evolution of a software system l Maintenance types are Maintenance for repair Maintenance for a new operating environment Maintenance to implement new requirements

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