Manag ing Software Change

1. Managing Software Change CIS 376 Bruce R. Maxim UM-Dearborn

2. Software Change • Software change is inevitable • New requirements emerge as software is used • Business environment may change • Errors need to be repaired • New equipment needs to be accommodated • May need to improve performance or reliability • A key problem for companies is implementing and managing change to their legacy systems

3. Software Change Strategies • Software Maintenance • Changes are made in response to changed requirements but the functional software structure is sound • Architectural Transformation • System may be modified from mainframe to distributed architecture • Software Re-engineering • Software restructured to facilitate future changes, no new functionality is added

4. Program Evolution Dynamics – part 1 • The study of the processes of system change • Lehman and Bundy proposed several observations after studying changes made to large systems • Continuing Change • A program used in the real-world must change or become progressively less useful in that environment. • Increasing Complexity • As an evolving program changes, its structure becomes more complex and extra resources must be devoted to preserving and simplifying the structure.

5. Program Evolution Dynamics – part 2 • Large Program Evolution • Program evolution is a self-regulating process. Some attributes (e.g. size, time between releases, # reported errors) are invariant for each system release. • Organizational Stability • Over a program’s lifetime its rate of development is approximately constant and independent of the resources devoted to system development. • Conservation of Familiarity • Over the lifetime of a system, the incremental change in each release is approximately constant.

6. Applicability of Lehman’s Laws • They seem to apply to large custom made systems developed by large organizations • It is not clear how they need to be modified for • Shrink-wrapped software products • Systems containing several COTS components • Small organizations • Medium sized systems

7. Maintenance is Inevitable • System requirements are likely to change while the system is being developed because their environment is changing • Systems are tightly coupled to their environment • When a system is installed it changes the environment and that can change the system requirements • The delivered system may not meet its requirements • Systems must be maintained to remain useful in their environment

8. Types of Maintenance • Corrective Maintenance (21%) • making changes to repair defects • Adaptive Maintenance (25%) • making changes to adapt software to a different environment (hardware, business rules, OS, etc.) • Perfective Maintenance (50%) • modifying system to meet new client requirements • Preventative Maintenance (4%) • eliminating potential problems before they appear

9. Spiral Maintenance Model

10. Maintenance Costs • Usually greater than the development costs (2 to 10 times as much in some cases) • Affected by both technical and non-technical factors • Increase as software is maintained and system corruption is introduced • Aging software can have high support costs (e.g. old languages, compilers, etc.)

11. Maintenance Cost Factors • Staff turnover • no turnover usually means lower maintenance costs • Contractual responsibility • developers may have no contractual obligation to maintain the delivered system and no incentive to design for future change • Staff skills • maintenance staff are often inexperienced and have limited domain knowledge • Program age and structure • as programs age their structure deteriorates, they become harder to understand and change

12. Maintenance Process

13. Change Requests • Requests can come from users, customers, or management • Change requests should be carefully analyzed as part of the maintenance process before they are implemented • Some changes requests must be implemented urgently due to their nature • fault repair • system environment changes • urgently required business changes

14. Maintenance Prediction • Concerned with determining 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 degrade system and reduces its maintainability • Maintenance costs depends on number of changes • Costs of change depend on maintainability

15. Maintenance Prediction

16. Change Prediction • Predicting the number of changes requires understanding the relationships between a system and its environment • Tightly coupled systems require changes whenever the environment changes • Factors influencing the system/environment relationship • number and complexity of system interfaces • number and volatility of system requirements • business processes where the system is used

17. Maintenance Complexity Metrics • Predictions of maintainability can be made by assessing component complexities • Most maintenance efforts only affect a small number of system components • Maintenance complexity depends on • complexity of control structures • complexity of data structures • module size

18. Maintenance Process Metrics • Maintainability measurements • number of requests for corrective maintenance • average time required for impact analysis • average time to implement a change request • number of outstanding change requests • If any if these increases it may signal a decline in maintainability

19. Architectural Evolution • Concerned with the need to covert legacy mainframe systems to client-server architectures • Change drivers • hardware costs (servers are cheaper than main frames) • user interface expectations (users expect GUI’s) • distributed system access (users want to use the system from geographically separated computers)

20. Factors Influencing System Distribution Decisions • Business importance • if distribution provides more efficient support for stable business processes then it is more likely to be cost-effective • System age • the older the system the harder it will be to modify its architecture due to degradation introduced by previous changes • System structure • the more modular the system the easier it will be to change the architecture • Hardware procurement policies • distribution may be necessary if mainframes are not replaced

21. Layered Distribution Model • Presentation Layer • concerned with display and organization of end-user screens • Data Validation Layer • concerned with validity of data input by user and output to user • Interaction Layer • concerned with managing sequence of end-user operations and sequence of screens presented to end-user • Application Services Layer • concerned with basic computations provide by the aplication • Database layer

22. Legacy System Distribution

23. Distribution Options • The more that is distributed from server to the client the higher the cost of evolution • The simplest distribution model is UI distribution where only the user interface is implemented on the client machine • The most complex distribution option is where the server simply provides data management and application services are implemented on the client

24. Distribution Option Spectrum

25. UI Distribution • Takes advantage of the local processing power found on the user’s workstation • The legacy system can be modified to distribute the user interface only when there is a clear separation between the user interface and application • If the separation is not clear, then screen management middleware can be used to translate text interfaces to GUI’s

26. User Interface Distribution

27. UI Migration Strategies - part 1 • Implementation using the workstation window management system • advantage • have unrestricted access to all UI functions • disadvantage • platform dependent • may be harder to achieve interface consistency

28. UI Migration Strategies - part 2 • Implementation using a web browser • advantage • platform independent • lower training costs • easier to achieve interface consistency • disadvantage • potentially poorer UI performance • interface design is constrained by browser capabilities