Software Evolution Massimo Felici Massimo Felici Software - PowerPoint PPT Presentation

Software Evolution Massimo Felici Massimo Felici Software Evolution � 2011 c

Title Slide Acknowledgements: James Bednar, Massimo Felici, Conrad Hughes, Perdita Stevens

1 Change is inevitable Even brand-new systems will often or typically need to: • Interface with existing components that cannot be replaced (usually undocumented, sometimes without source code) • Reproduce functionality of old, badly designed systems in current use, without breaking anything • Go through many revisions during development Massimo Felici Software Evolution � 2011 c

2 What is software evolution? Change over time • all kinds of maintenance: corrective, adaptive, perfective, preventive • reengineering • end-of-life, system withdrawal Various experts have asserted that most of the cost of software ownership arise after delivery, i.e. during maintenance — e.g. > 90% ! (Erlikh, 2000) However, evolution is not as maintenance (Lutz, Mikulski, 2003) Massimo Felici Software Evolution � 2011 c

Slide 2: What is software evolution? The process by which programs change over time, e.g. for: • Maintenance: Fixing bugs, adapting when external components change, adding features • Reverse engineering: Analysing an existing system, e.g. to create accurate documentation • Refactoring: Cleaning up code without modifying functionality • Reengineering: Creating a maintainable system out of an unmaintainable one (at a larger scale than refactoring) • Len Erlikh. 2000. Leveraging Legacy System Dollars for E-Business. IT Professional 2, 3 (May 2000), 17-23. http://dx.doi.org/10.1109/6294. 846201 • Robyn R. Lutz and Ines Carmen Mikulski. 2003. Operational anomalies as a cause of safety-critical requirements evolution. J. Syst. Softw. 65, 2 (February 2003), 155-161. http://dx.doi.org/10.1016/S0164-1212(02)00057-2

3 Why does software need to change? • because it wasn’t built right • because something has changed: business environment, software environment, hardware environment... Massimo Felici Software Evolution � 2011 c

4 Kinds of maintenance More precisely, even though software doesn’t wear out in the same was as physical artifacts, it still needs to be: • fixed (corrective maintenance), • adapted to changing needs (adaptive maintenance), • improved in performance or maintainability (perfective maintenance) • improved by fixing bugs before they activate (preventive maintenance) Massimo Felici Software Evolution � 2011 c

Slide 4: Kinds of maintenance • ISO/IEC 14764, Software Engineering – Software Life Cycle Processes – Maintenance following Swanson’s dimensions • E. Burton Swanson. 1976. The dimensions of maintenance. In Proceedings of the 2nd international conference on Software engineering (ICSE ’76). IEEE Computer Society Press, Los Alamitos, CA, USA, 492-497.

5 What should we think of this? • Success: tells of flexible systems that needn’t be thrown away? • Failure: tells of systems that aren’t correct or flexible as built? • Whatever... figures like these do tell us that how maintenance is done is important: doing it better may save money. (And doing it less may too, of course.) Massimo Felici Software Evolution � 2011 c

6 Lehman’s laws Manny Lehman, the “Father of Software Evolution”, wrote many papers from the mid 70s onwards, proposing “Laws of Software Evolution” for “E-type systems”. Systems classified into: • S-type: formally specified and verified; static by definition • E-type: real-world system Massimo Felici Software Evolution � 2011 c

7 Lehman’s laws (adapted from 2001 talk by MML) I Continuing Change An E-type system must be continually adapted else it becomes progressively less satisfactory in use II Increasing As an E-type system is evolved its complexity increases unless work is Complexity done to maintain or reduce it III Self regulation Global E-type system evolution processes are self-regulating IV Conservation of Average activity rate in an E-type process tends to remain constant Organisational Stability over system lifetime or segments of that lifetime V Conservation of In general, the average incremental growth (growth rate trend) of Familiarity E-type systems tends to decline VI Continuing Growth The functional capability of E-type systems must be continually enhanced to maintain user satisfaction over system lifetime VII Declining Unless rigorously adapted to take into account changes in the Quality operational environment, the quality of an E-type system will appear to be declining as it is evolved VIII Feedback E-type evolution processes are multi-level, multi-loop, multi-agent System feedback systems Massimo Felici Software Evolution � 2011 c

8 Criticism of Lehman’s laws • “Laws”? • Based on data? • Contentful? Massimo Felici Software Evolution � 2011 c

9 Two kinds of scenario Let us consider separately: • Business-as-usual software evolution: how things should work • Disaster recovery software evolution: coping when things don’t work properly Massimo Felici Software Evolution � 2011 c

10 Managing change Realising that software evolution is normal and necessary, have a process in place: 1. A bug report or change request is submitted, e.g. via an issue tracking tool; 2. Show-stopping problems may have to be dealt with immediately (maybe even by a binary patch); 3. But as a general rule, issues and bugs are classified and prioritised; 4. Subsequent software releases incorporate fixes for a selection of reported issues. There is always a trade-off between fixing old issues and introducing new functionality. Some problems are cheap to live with. Massimo Felici Software Evolution � 2011 c

11 Why evolution doesn’t always go smoothly • Maintenance is seen as uninteresting and low-status: hard to get the best developers to spend long on a maintenance team. • There is always more work than can be done, so corners tend to be cut. • Even if resource isn’t an issue, the intention behind the original design is easily lost. • So the software gradually loses its integrity: architectural degradation . Massimo Felici Software Evolution � 2011 c

12 Legacy Systems A system which still has value, but which significantly resists modification and evolution. Stereotypically old – but that can mean 5 years. Problems include: • architectural degradation • reliance on unmaintained software or hardware • loss of expertise • not designed for evolution Massimo Felici Software Evolution � 2011 c

Slide 12: Legacy Systems A legacy system is one that is difficult to evolve. • Cynical definition 1: legacy = any system actually being used. Systems are obsolete as soon as they are shipped — technology evolves, requirements change, etc., yet, it is always difficult to make changes without disrupting existing users. • Cynical definition 2: legacy = any system without a complete test suite. Without good tests, making changes is scary, so people become conservative rather than doing large-scale maintenance like refactoring. Without constant vigilance (continuous refactoring and reengineering), this tradeoff results in a series of small, scattered patches that eventually destroy system integrity and make systems unmaintainable.

13 Bad situations • There is a system: it is in use, but nobody deeply understands how it works. It needs to be changed, but there’s a problem. • Maybe its source code is a mess. • Maybe it can no longer be compiled. • Maybe its source code has even been lost! (Perhaps only partially.) Massimo Felici Software Evolution � 2011 c

14 So what to do? Basically three options: • Soldier on • Reengineer • Scrap The attempt to understand the system is an essential part of the decision process. Massimo Felici Software Evolution � 2011 c

15 Techniques for understanding legacy systems • Program comprehension tools can help, well, comprehend the program. Many techniques can be used, providing different information useful in different circumstances. For example, a slicing tool can be used to identify which lines of a program affect the value of a specific variable at a point of interest. • Reverse engineering tools construct a high level view of a system from a low level one. This may be source code from object code (useful if source code has been lost), a call graph in which nodes representing modules or functions are connected if one calls the other, or perhaps a UML class diagram. Massimo Felici Software Evolution � 2011 c

16 And then what? If only small modifications are needed, may now be able to modify and rebuild the system, even if much of it is still undocumented. Or it may be more cost-effective to replace or reengineer. E.g. • Reengineer: renovate the system by restoring a suitable architecture and updating as needed. • Replace in a fairly mechanical way (with or without automation): e.g., where a system is written in an obsolete language, have it translated function-by- function into a modern language. • Replace, starting from gathering current requirements. Consider using COTS (commercial off-the-shelf) software. Massimo Felici Software Evolution � 2011 c