1 / 35

Software change

Software change. Managing the processes of software system change. 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

galia
Download Presentation

Software change

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related