Software change

1. Software change • Managing the processes of software system change

2. Software change • 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 • A key problem for organisations is implementing and managing change to their legacy systems

3. Software change strategies • Software maintenance • Architectural transformation • Software re-engineering • These strategies may be applied separately or together • Alternative – complete replacement from scratch

4. Program evolution dynamics • Study of the processes of system change • Lehman and Belady proposed ‘laws’ concerning the evolution of systems • They are applicable to large systems developed by large organizations.

5. Lehman’s First Law • Continuing Change • Environment changes • New requirements • Not controversial

6. Lehman’s Second Law • Increasing Complexity • To combat this takes effort • Such extra effort is rarely done • Not controversial

7. Lehman’s Third Law • Large Program Evolution • System attributes (size, time between releases, error rates) are invariant from release to release • Determined by organizational practices and system structure • Is controversial

8. Lehman’s Fourth Law • Organization Stability • Rate of development approximately constant • Determined by organizational practices and system structure • Is controversial

9. Lehman’s Fifth Law • Conservation of familiarity • Over lifetime of system, incremental change in each release is approximately constant

10. Applicability of Lehman’s laws • 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

11. 27.2 Software maintenance • 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

12. Maintenance is inevitable • The system requirements are likely to change • When a system is installed it changes the environment and therefore changes the system requirements. • Systems MUST be maintained therefore if they are to remain useful in an environment

13. Types of maintenance • Repair software faults • Adapt software to a different operating environment • Add to or modify the system’s functionality

14. Distribution of maintenance effort

15. Spiral maintenance model

16. Maintenance costs • Usually greater than development costs • Affected by both technical and non-technical factors • Increases as software is maintained. • Ageing software can have high support costs

17. Development/maintenance costs

18. Maintenance cost factors • Team stability • Contractual responsibility • Staff skills • Program age and structure

19. The maintenance process

20. Change requests • 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

21. Change implementation Emergency repair

22. Maintenance prediction • Change acceptance affected by the maintainability of the components affected by the change • Maintenance prediction is concerned with assessing which parts of the system may cause problems and have high maintenance costs

23. Maintenance prediction

24. Change prediction • Requires an 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

25. Maintainability Prediction • Most maintenance effort on small number components • Prediction of maintainability based on complexity • Complexity metrics • Complexity of control structures • Complexity of data structures • Procedure and module size • It may be beneficial to replace complex components

26. Maintainability Prediction via Process metrics • 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 • If any or all of these are increasing, this may indicate a decline in maintainability

27. Architectural evolution • The architecture of the system is modified. • There is a need to convert many legacy systems from a centralized architecture to a client-server architecture • Change “drivers” • Hardware costs. • User interface expectations. • Distributed access to systems.

28. Distribution factors

29. Legacy system structures U s e r i n t e r f a c e U s e r i n t e r f a c e S e r v i c e s S e r v i c e s D a t a b a s e D a t a b a s e Ideal model for distribution Real Legacy Systems

30. Legacy system distribution

31. Layered distribution model

32. Distribution option spectrum

33. User interface distribution • 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

34. User interface distribution

35. UI Migration Strategies