©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 1 Chapter 21 Software Evolution

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 2 Objectives l To explain why change is inevitable (if software systems are to remain useful) l To describe different types of software maintenance l To identify maintenance cost factors l To describe the maintenance prediction process

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 3 Topics covered l Software change l Program evolution dynamics l Software maintenance and maintenance types l Maintenance costs and cost factors l Maintenance prediction

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 4 Topics covered l Software change l Program evolution dynamics l Software maintenance and maintenance types l Maintenance costs and cost factors l Maintenance prediction

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 5 Why software changes l Software change is inevitable…  New requirements emerge when the software is used;  The business environment changes;  Errors must be repaired;  New computers and equipment are added to the system;  The performance or reliability of the system may have to be improved.

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 6 Why effective change management is critical l The ability to implement and manage change is critical since…  Organizations have huge investments in their software systems - they are critical business assets.  To maintain the value of these assets, they must be changed and updated as necessary. l In fact, most of the software budget in large companies is devoted to evolving existing software rather than developing new software.

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 7 Spiral model of evolution

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 8 Topics covered l Software change l Program evolution dynamics l Software maintenance and maintenance types l Maintenance costs and cost factors l Maintenance prediction

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 9 l …is the study of the processes of system change. l After major empirical studies, Lehman and Belady proposed a number of “laws” which apply to large systems as they evolved. l They are actually sensible observations rather than “laws.” Program evolution dynamics…

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 10 Lehman’s laws (the “saturated state” idea) (how to apply this?)

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 11 Limits of applicability l Lehman’s laws seem to be generally applicable to large, custom systems developed by large organizations. (But what about systems such as MS Word which originally operated in 256K of memory, but which is now a giant requiring many megabytes of memory?) (cont’d)

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 12 Limits of applicability (cont’d) l Also, it is not clear how the laws should be modified for  Shrink-wrapped software products;  Systems that incorporate a significant number of COTS components;  Small organizations;  Medium sized systems.

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 13 Topics covered l Software change l Program evolution dynamics l Software maintenance and maintenance types l Maintenance costs and cost factors l Maintenance prediction

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 14 l Modifying a program after it has been put into use to effect software change l Does not normally involve major changes to the system’s architecture l Changes are implemented by modifying existing components and/or adding new components to the system. Software “maintenance”

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 15 l Maintenance to repair software faults l Maintenance to adapt software to a different operating environment l Maintenance to add to or modify the system’s functionality Types of maintenance

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 16 l Maintenance to repair software faults l Maintenance to adapt software to a different operating environment l Maintenance to add to or modify the system’s functionality How is maintenance effort typically divided among these three activities? Types of maintenance

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 17 Distribution of maintenance effort

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 18 Topics covered l Software change l Program evolution dynamics l Software maintenance and maintenance types l Maintenance costs and cost factors l Maintenance prediction

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 19 l Usually greater than development costs (2 to 100 times greater depending on the application). l Affected by both technical and non-technical factors. l Increases as software is maintained. (Maintenance corrupts the software structure so makes further maintenance more difficult.) l Ageing software can have very high support costs (e.g. old languages, compilers etc.). Maintenance costs

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 20 Development/maintenance costs reducing lifetime costs by spending more to increase maintainability during development

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 21 So what factors affect maintenance costs? Maintenance cost factors

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 22 l Team stability: Maintenance costs are reduced if the same staff are involved with the system for some time. l Contractual responsibility: The developers of a system may have no contractual responsibility for maintenance so there is no incentive to design for future change. (cont’d) Maintenance cost factors (cont’d)

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 23 l Staff skills: Maintenance staff are often inexperienced and have limited domain knowledge. l Program age and structure: As programs age, their structure is degraded and they become harder to understand and change. Maintenance cost factors (cont’d)

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 24 Topics covered l Software change l Program evolution dynamics l Software maintenance and maintenance types l Maintenance costs and cost factors l Maintenance prediction

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 25 Maintenance prediction… l …is concerned with assessing which parts of the system will be affected by change and what the costs of change will be. l This involves predicting:  Number of changes that will be required and the system parts that will be impacted;  Maintainability of different system parts; and  Short- and long-term cost of maintenance.

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 26 Maintenance prediction (cont’d) What parts of the system are most likely to be affected by change requests? What parts of the system will be the most expensive to maintain?

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 27 Maintenance prediction (cont’d) What parts of the system are most likely to be affected by change requests? What parts of the system will be the most expensive to maintain?

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 28 Change prediction l Predicting the number of changes requires an understanding of the relationships between a system and its environment. (Tightly coupled systems require changes whenever the environment is changed.) (cont’d)

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 29 Change prediction (cont’d) l Factors influencing this coupling are:  Number and complexity of system interfaces;  Number of inherently volatile system requirements; and  The business processes associated with system use. (cont’d)

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 30 Maintenance prediction (cont’d) What parts of the system are most likely to be affected by change requests? What parts of the system will be the most expensive to maintain?

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 31 Product metrics l Studies have shown that most maintenance effort is spent on a relatively small number of system components. l Predictions of maintainability can be made by assessing the complexity of system components. E.g.,  Complexity of control structures;  Complexity of data structures;  Object, method (procedure) and module size. (See, for example: Identifying Error-Prone Software - An Empirical Study (S.M. Thebaut, V.Y. Shen, T.J. Yu, and L.R. Paulsen), IEEE Transactions on SE 11(4): , 1985.

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 32 Process metrics l Process measurements taken over time may also 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 unresolved change requests. l If any of these are increasing, it may indicate a decline in maintainability.

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 33 Maintenance prediction (cont’d) What parts of the system are most likely to be affected by change requests? What parts of the system will be the most expensive to maintain?

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 34 Cost prediction l Use predicted change request and maintainability info together with intuition and experience to predict costs. l Cost estimation models (e.g., Boehm’s COCOMO 2) utilize estimates of program understandability and new code development effort to predict costs. (See Chap. 26.)

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 35 Key points l Software development and evolution should be seen as a single, iterative process. l Lehman’s “Laws” describe a number of insights into system evolution. l Three types of maintenance are: bug fixing, adapting software for a new environment, and adding/modifying functionality. l For custom systems, maintenance costs usually far exceed development costs.

©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 36 Chapter 21 Software Evolution