Software Change

1. Software Change IS301 – Software Engineering Lecture # 25 – 2003-11-18 M. E. Kabay, PhD, CISSP Dept of Computer Information Systems Norwich University mkabay@norwich.edu

2. Topics • Program Evolution Dynamics • Software Maintenance • Architectural Evolution

3. Software Change (1) • Managing processes of software system change

4. Software Change (2) • Software change inevitable • New requirements emerge when software used • Business environment changes • Errors must be repaired • New equipment must be accommodated • Performance or reliability may have to be improved • Key problem for organizations: • Implementing and managing change to legacy systems

5. Software Change Strategies • Software maintenance • Response to changed requirements • Fundamental software structure stable • Architectural transformation • Generally from centralized architecture to distributed architecture • Software re-engineering • No new functionality added • Restructured and reorganized • To facilitate future changes • Strategies may be applied separately or together

6. Program Evolution Dynamics • Study of processes of system change • Lehman and Belady • Major empirical study • Proposed ‘laws’ applying to all systems as they evolved • Sensible observations rather than laws • Applicable to large systems developed by large organizations • Perhaps less applicable in other cases

7. Lehman’s Laws • Continuing Change • Increasing Complexity • Large Program Evolution • Organizational Stability • Conservation of Familiarity

8. Continuing Change • A program used in a real-world environment must necessarily change or it will progressively become less useful in that environment.

9. 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.

10. 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.

11. Organizational Stability • Over a program’s lifetime, its rate of development is approximately constant and independent of the resources devoted to system development.

12. Conservation of Familiarity • Over the lifetime of a system, the incremental change in each release is approximately constant.

13. Applicability of Lehman’s Laws • Not yet been established • Generally applicable to • Large, tailored systems • Developed by large organizations • Not clear how they should be modified for • Shrink-wrapped software products • Systems that incorporate significant number of COTS components • Small organizations • Medium sized systems

14. Topics • Program Evolution Dynamics • Software Maintenance • Architectural Evolution

15. Software Maintenance • Modifying program after it has been put into use • Does not normally involve major changes to system’s architecture • Changes are implemented by • Modifying existing components and • Adding new components to system

16. Maintenance Inevitable • System requirements likely to change while system being developed • Because environment changing • Therefore delivered system won't meet its requirements (!) • Systems tightly coupled with their environment • When system installed in environment it changes that environment • Therefore changes system requirements • Systems MUST be maintained if they are to remain useful in their environment

17. Tool/Problem Relation Availability of a tool changes the perception of what is possible

18. Types of Maintenance • Repair software faults • Adapt software to different operating environment (e.g., new computer, OS) • Add to or modify system’s functionality

19. Distribution of Maintenance Effort

20. Spiral Maintenance Model

21. Maintenance Costs • Usually greater than development costs (2* to 100* depending on application) • Affected by both technical and non-technical factors • Increases as software maintained • Maintenance corrupts software structure thus making further maintenance more difficult • Ageing software can have high support costs (e.g. old languages, compilers etc.)

22. Development/Maintenance Costs

23. Maintenance Cost Factors • Team stability • $$ reduced if same staff involved with them for some time • Contractual responsibility • Developers of system may have no contractual responsibility for maintenance • So no incentive to design for future change • Staff skills • Maintenance staff often inexperienced and may have limited domain knowledge • Program age and structure • As programs age, their structure degraded and they become harder to understand and change

24. Evolutionary Software • Rather than think of separate development and maintenance phases, evolutionary software software designed to evolve continuously throughout its lifetime.

25. Maintenance Process

26. Change Requests • Change requests for system changes • From users, customers or management • In principle • All change requests should be carefully analyzed • Part of orderly maintenance process • In practice, some change requests must be implemented urgently • Fault repair • Changes to system’s environment • Urgently required business changes

27. Change Implementation

28. Emergency Repair

29. Maintenance Prediction • Assessing which parts of system may cause problems and have high maintenance costs • Implementing changes degrades system and reduces its maintainability • Maintenance costs depend on number of changes and • Costs of change depend on maintainability

30. Maintenance Prediction

31. Change Prediction • Predicting number of changes requires and understanding of relationships between system and its environment • Tightly coupled systems require changes whenever environment changed • Factors influencing this relationship • Number and complexity of system interfaces • Number of inherently volatile system requirements • Business processes where system used

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

33. 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 change request • Number of outstanding change requests • If any or all of these increasing, this may indicate decline in maintainability

34. Topics • Program Evolution Dynamics • Software Maintenance • Architectural Evolution

35. Architectural Evolution • Need to convert many legacy systems from centralized architecture to client-server architecture • Drivers for change: • Hardware costs: Servers cheaper than mainframes • User interface expectations: Users expect graphical user interfaces • Distributed access to systems: Users wish to access system from different, geographically separated, computers

36. Distribution Factors

37. Legacy System Structure • Ideally, for distribution, there should be clear separation between • user interface, • system services and • system data management • In practice, these are usually intermingled in older legacy systems

38. Legacy System Structures

39. Layered Distribution Model

40. Legacy System Distribution

41. Distribution Options • The greater the amount of processing shifted from server to client, the higher the costs of architectural evolution • Simplest distribution model • UI distribution • Only user interface implemented on client • “Thin client” • Most complex option • Server simply provides data management • Application services implemented on client • “Fat client”

42. Distribution Option Spectrum

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

44. User Interface Distribution

45. UI Migration Strategies

46. Homework • Read Chapter 27 thoroughly using the full SQ3R techniques. • Begin studying Chapter 28 on software re-engineering using the Survey-Question phases of SQ3R in preparation for Thursday’s class. • For Tuesday the 2nd of Dec, complete exercises 27.1 through 27.8 for a total of 24 points. Expect to answer these questions in about ¼ to ½ a page of text each.

47. DISCUSSION