1. Chapter 8: Maintenance and Software Evolution Ronald J. Leach Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 1

2. Software Maintenance Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 2

3. Hardware and software maintenance are different Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 3 Typical “bathtub curve for hardware failures

4. Software must be maintained 1.Hardware platforms change or become obsolete. 2.Operating systems change or become obsolete. 3.Compilers change or become obsolete. 4.Language standards change or become obsolete. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 4

5. Software must be maintained 5.Communications standards change or become obsolete. 6.Graphical user interfaces change or become obsolete. 7.Related applications software packages change or become obsolete. 8.Relationships with developers of other applications or systems software change. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 5

6. Software must be maintained 9.Software defects noted by customers must be corrected. 10.Customers demand new features. 11.Software needs upgrades to be competitive with new competition. 12.Existing software errors must be prevented from occurring in new releases of the software. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015

7. How to Read Requirements, Design, and Source Code Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 7

8. Old adage: If the source code and any of the requirements, design, or documentation do not agree, they’re all wrong Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 8

9. Suggestions Look for similar cases Look at the IDE or CASE tool where the software was created Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 9

10. Corrective Maintenance Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 10

11. Corrective Maintenance Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 11 Observation that a problem exists. Documentation of the problem. Determination of importance. Prioritizing problems in order of importance. Determining which problems will not be repaired, due to insufficient resources. Solution of the problem.

12. Corrective Maintenance Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 12 Testing the system to see if the fix to this problem causes any other faults. Documenting the solution in source code. Documenting changes have been made to the original system design. Updating a database of information about software errors.

13. Fred Brooks ’ View ”…as a consequence of the introduction of new bugs, program maintenance requires far more system testing per statement written than any other programming. “ (“The Mythical Man Month”) Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 13

14. Fred Brooks ’ View, cont. ”Theoretically, after each fix, one must run the entire batch of test cases previously run against the system, to ensure that it has not been damaged in an obscure way. In practice, such regression testing must indeed approximate this theoretical idea, and it is very costly." (The Mythical Man Month”) Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 14

15. Adaptive Maintenance Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 15

16. Need to respond to changes In technology In the marketplace Even worse if the technology is disruptive Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 16

17. Software Evolution Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 17

18. Software Evolution Some software is so long-lived that its maintenance changes are best described as “evolution.” Especially true for rapidly changing technology environments Even true for COTS products and large-scale components Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 18

19. Buy vs. Build vs. Reuse vs. Reengineer Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 19

20. Always the decision to be made Factors include: – Total life cycle costs to date (presumed known) – Total life cycle costs expected in the future (only meaningful if the cost models used have been reasonably accurate – Technology assessment predictions Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 20

21. Always the decision to be made Factors include: – Total life cycle costs to date – Expected costs to buy – Expected costs to reuse – Expected costs to reengineer – Balancing the decision against the commitment of resources that could be used elsewhere Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 21

22. Typical cost allocation for short- lived software systems with minimal maintenance Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 22

23. Typical cost allocation for short- lived software systems with some maintenance Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 23

24. Typical cost allocation for short- lived COTS-based software systems with minimal maintenance Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 24

25. Typical cost allocation for COTS- based software systems that have to be replaced every few years Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 25

26. Suggestions Collect data on how projects spend money. Map this data over time to get a graphical image of how costs increased when new releases of COTS products occurred and had to be incorporated into a system. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 26

27. Suggestions, cont. Keep data on how much up-front systems analysis and COTS evaluation costs and how long they take. Consider the use of some less-expensive, junior-level personnel as part of the COTS evaluation team, at least for the second or third iteration of the COTS-based system. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 27

28. Suggestions, cont. Plan to reduce the number of senior-level people kept on long-term projects, by phasing in some of the more junior personnel. You’ll probably have to do it anyway, because talented people want professional growth! Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 28

29. Suggestions, cont. Make sure there are at least a few domain experts and senior software engineers always available, even if you have to pay more. Consultants may be of assistance in filling some portion, but not all, of this role. Learn from your mistakes! Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 29

30. Agile Development Case Study: Maintenance and Evolution Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 30

31. The nature of agile development Rapid development of well-tested software in cooperation with a “customer.” It is highly unlikely that any significant portion of the agile development team will be around the organization during maintenance. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 31

32. Agile development and maintenace Few agile developers work on software maintenance Maintenance requires considerable effort understanding programs before systems can be maintained. Little reliable data on the cost of maintaining agile systems. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 32

33. An opportunity Software developed using agile processes is often created faster than faster than similar projects using other methods. Are the agile projects “better?” Are total life cycle costs lower, higher, or the same? How can we tell what’s best for our organization? Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 33

34. The solution Use maintenance information to analyze quality and other metrics on different types of software development processes. The goal is process improvement. NOTE: this analysis of maintenance data is not part of an agile process, but it is part of software engineering! Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 34

35. Maintenance of the Major Continuing Software Development Project Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 35

36. Maintenance occurs after delivery What happens next in a software engineering course after the semester is over? New features Improved design Increased security … Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 36

37. Suggested new features Migrate to a new operating system Move to a new platform Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 37

38. Suggested new design Move to a Macintosh Move to a Linux or UNIX system Move some data to a tablet or smart phone Improve visualization Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 38

39. Improve security Always! Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 39

40. An opportunity The major continuing software development project used a particular software development process, perhaps different ones for different teams using other methods. How can we tell what worked best? Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 40

41. The solution Use maintenance information to analyze quality and other metrics on different types of software development processes. The goal is process improvement. NOTE: this analysis of maintenance data is a critical part of software engineering! Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 41