1. © Keith Vander Linden, 2011 1 Dilbert © United Feature Syndicate, Inc.

2. © Keith Vander Linden, 2011 2 Software Evolution ● The Transition Phase The Transition Phase ● The show hits the road: – Deployment Deployment – Maintenance Maintenance – Re-engineering Re-engineering ● A final word… A final word… An airplane is nothing more than a collection of parts having an inherent tendency to fall to earth, and requiring constant effort and supervision to stave off that outcome. – K. Gorlen UNIX System V

3. © Keith Vander Linden, 2011 3 The Transition Phase ● In the UP transition phase, the system is transferred to the user community. ● It’s activities include: – Deployment – Technical support and training – Maintenance ● Software Systems evolve over time.

4. © Keith Vander Linden, 2011 4 Relative Effort: Phases data from Schach, 2002

5. © Keith Vander Linden, 2011 5 System Deployment ● Deployment is not the end of the road. – Packaging/distribution – Installation ● Systems are deployed as an architecture of physical devices and software environments.

6. © Keith Vander Linden, 2011 6 Deployment Diagrams ● Their physical architectures have the following elements: – Physical devices – Software execution environments – Software artifacts – Communication lines ● UML Deployment Diagrams can be used to communicate these architectures.

7. © Keith Vander Linden, 2011 7 Example: Deployment Diagram Example adapted from Fowler, 2003

8. © Keith Vander Linden, 2011 8 Outline ● Deployment Diagrams – Nodes Nodes – Artifacts Artifacts – Associations Associations ● Using Deployment Diagrams Using Deployment Diagrams

9. © Keith Vander Linden, 2011 9 Nodes ● Deployment diagram nodes can represent: – Physical devices – Software execution environments ● These stereotypes are helpful, but are not standardized.

10. © Keith Vander Linden, 2011 10 Artifacts ● Artifacts are the physical manifestations of software components. ● They are stored on/in nodes.

11. © Keith Vander Linden, 2011 11 Assocations ● Associations represent communication paths and protocols.

12. © Keith Vander Linden, 2011 12 Using Deployment Diagrams ● Use deployment diagrams to show: – what is deployed where; – how the communication flows. ● Any non-trivial deployment can benefit from their use.

13. © Keith Vander Linden, 2011 13 Legacy Systems ● Systems can eventually become legacy systems. ● Legacy systems: – are entrenched; – have ceased to evolve; – continue to be used because their replacement cost is too high.

14. © Keith Vander Linden, 2011 14 System Maintenance ● Maintenance sustains a software system throughout its life-cycle. ● Software deteriorates as it evolves. ● Reasons for post-delivery modification: – Corrective maintenance – Perfective maintenance – Adaptive maintenance

15. © Keith Vander Linden, 2011 15 Relative Effort: Maintenance Types data from: Schach et al, 2003

16. © Keith Vander Linden, 2011 16 The Joy of Maintenance ● Maintenance is seen as – an after-the-fact activity – unrelated to the software development ● Problems: – Users are usually dissatisfied. – Problems are frequently caused by someone else. – You’re on the bottom rung of the life-cycle food-chain. – There are limited support tools.

17. © Keith Vander Linden, 2011 17 Change Management Tools ● Managing defects ● Fixing defects ● Testing fixes

18. © Keith Vander Linden, 2011 18 Regression Testing re·gres·sion (re -greh shun) n. Relapse to a less perfect or developed state. ● Changing software tends to break things. ● Regression testing checks that the system still operates properly after change.

19. © Keith Vander Linden, 2011 19 Engineering for Evolution ● Good software engineering should anticipate evolution. ● Silver bullets? – “Heavy” software engineering? – Object-Oriented design? – Agile development?

20. © Keith Vander Linden, 2011 20 Re-Engineering ● Re-implementing an existing system, with minimal analysis and design, e.g.: – Re-documenting a system – Re-structuring a system – Translating a system code to a newer language – Porting a system to a new platform ● This can be cheaper than developing a new system or fixing an old one.

21. © Keith Vander Linden, 2011 21 Reasons to Re-Engineer ● To support a more modern platform ● To move to a better supported language ● To improve efficiency ● To make the system more understandable in order to support maintenance

22. © Keith Vander Linden, 2011 22 Types of Re-Engineering Cheap Expensive Automated Code conversion Manual architectural restructuring Automated Program restructuring Manual program/data restructuring from: Sommerville, 2001

23. © Keith Vander Linden, 2011 23 Reverse Engineering ● The process of deriving abstract formal specifications from the source code of a legacy system ● This is used to support: – System re-engineering – System replacement

24. © Keith Vander Linden, 2011 24 image from: http://www.unc.edu/ Fredrick P. Brooks (1931- ) The Mythical Man-Month ● Brooks considered evolution to be one of the essential characteristics of software systems. ● He gives the following advice to young managers: Numquam incertus; semper apertus What’s the Big Idea