1 Dilbert United Feature Syndicate Keith Vander Linden

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

2 Software Evolution ● ● The Transition Phase The show hits the road: Deployment – Maintenance – Re-engineering – ● 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 © Keith Vander Linden, 2009

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. © Keith Vander Linden, 2009

4 Relative Effort: Phases Analysis 7% Design 6% Implementation 13% Maintenance 67% Testing 7% data from Schach, 2002 © Keith Vander Linden, 2009

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. © Keith Vander Linden, 2009

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. © Keith Vander Linden, 2009

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

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

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

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

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

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. © Keith Vander Linden, 2009

13 Legacy Systems ● Systems eventually become legacy systems: – ● entrenched systems that cease to evolve, but continue to be used because their replacement cost is too high Two kinds of legacy systems: – The system you wish you could dig into: – The system you wish you hadn’t dug into: © Keith Vander Linden, 2009

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 © Keith Vander Linden, 2009

15 Relative Effort: Maintenance Types other Adaptive 2% 2% Perfective 39% Corrective 57% data from: Schach et al, 2003 © Keith Vander Linden, 2009

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. © Keith Vander Linden, 2009

17 Managing Change ● Defect reporting ● Authorizing changes ● Making changes ● Configuration Management ● Testing changes © Keith Vander Linden, 2009

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. © Keith Vander Linden, 2009

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

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. © Keith Vander Linden, 2009

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

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

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 – © Keith Vander Linden, 2009

24 Fredrick P. Brooks (1931 - ) The Mythical Man-Month ● ● What’s the Big Idea 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 image from: http: //www. unc. edu/ © Keith Vander Linden, 2009