1. Introduction to Software Evolution and Maintenance

2. Importance of evolution
Organizations have huge investments in their software systems - they are critical business assets.
To maintain the value of these assets to the business, they must be changed and updated.
The majority of the software budget in large companies is devoted to evolving existing software rather than developing new software.
Studies indicate that up to 75% of all software professionals are involved in some form of maintenance/evolution activity.
“Much of the software we depend on today is on average 10 to 15 years old”

3. Software change Software change is inevitable
New requirements emerge when the software is used;
The business environment changes;
Errors must be repaired;
New computers and equipment is added to the system;
The performance or reliability of the system may have to be improved.
A key problem for organizations is implementing and managing change to their existing software systems.

4. Software evolution and software maintenance
No standard definitions.
Broad definition of evolution: Generally, software evolution refers to the study and management of the process of making changes to software over time.
In this definition, software evolution comprises:
Development activities
Maintenance activities
Reengineering activities
Narrow definition of evolution: Sometimes, software evolution is used to refer to the activity of adding new functionality to existing software.
Maintenance refers to the activity of modifying software after it has been put to use in order to maintain its usefulness.

5. SEG4210 - Software Maintenance
“The modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a changed environment”
ANSI/IEEE Standard
SEG Software Maintenance 5 5

6. Types of changes Repair software faults
Changing a system to correct deficiencies in the way it meets its requirements. – corrective maintenance
Adapt software to a different operating environment
Changing a system so that it operates in a different environment (computer, OS, etc.) from its initial implementation. – adaptive maintenance
Add to or modify the system’s functionality
Modifying the system to satisfy new requirements. –perfective maintenance
Improve the program structure and system performance
Rewriting all or parts of the system to make it more efficient and maintainable.
“Maintenance”
“Evolution”
In the narrower sense of the word, “evolution” refers to changes that add functionality to the system.
“Reengineering”

7. Distribution of maintenance activities
corrective 21%
perfective 50%
adaptive 25%
preventive 4%

8. SEG4210 - Software Maintenance
Preventive Maintenance
Preventing failures by fixing defects in advance of failures
A kind of perfective maintenance
Key examples: Y2K and Daylight Savings adjustments
SEG Software Maintenance 8 8

9. Major causes of maintenance problems
Unstructured code
Insufficient domain knowledge
Insufficient documentation

10. Maintenance Examples Y2K Anti-Virus Software Operating System Patching
many, many systems had to be updated
language analyzers (find where changes need to be made)
Anti-Virus Software
don't usually have to update software, but must send virus definitions
Operating System Patching
Microsoft, Apple, Linux/Unix
OS is core to use of computer, so it must be constantly maintained
Commercial Software in General
customers need to be informed of updates
updates have to be easily available - web is good tool

11. Maintenance costs
Usually greater than development costs (2* to 100* depending on the application).
Affected by both technical and non-technical factors.
Increases as software is maintained. Maintenance corrupts the software structure so makes further maintenance more difficult.
Ageing software can have high support costs (e.g. old languages, compilers etc.).

12. Maintenance cost factors
Team stability
Maintenance costs are reduced if the same staff are involved with them for some time.
Contractual responsibility
The developers of a system may have no contractual responsibility for maintenance so there is no incentive to design for future change.
Staff skills
Maintenance staff are often inexperienced and have limited domain knowledge.
Program age and structure
As programs age, their structure is degraded and they become harder to understand and change.

13. Lehman’s laws
After major empirical studies, Lehman and Belady proposed that there were a number of ‘laws’ which applied to all systems as they evolved.
These are sensible observations rather than laws. They are applicable to large systems developed by large organisations. Perhaps less applicable in other cases.

14. Lehman’s laws

15. The system evolution process
Release
planning
Change
implementation
System r
elease
Impact
analysis
equests
Platform
adaptation
enhancement
Fault repair
Sommerville, Ch. 21

16. Change implementation
Proposed
Requirements
Requirements
Software
changes
analysis
updating
development
Sommerville, Ch. 21

17. SEG4210 - Software Maintenance
Software Maintenance Steps 1
Understand the existing system
Study whatever form of documentation exists about the system to be modified
Often the only reliable source of information is the source code
Use tools to recover the high-level design models of the system
Define the maintenance objectives
Set the requirements
SEG Software Maintenance 17 17

18. SEG4210 - Software Maintenance
Software Maintenance Steps 2
Analysis
Evaluate alternatives for handling the modification
Estimate the costs and benefits of the alternative modifications
Perform impact analysis
Determine the effect of the change on the rest of the system
Design, implement, and test the changes
SEG Software Maintenance 18 18

19. SEG4210 - Software Maintenance
Software Maintenance Steps 3
Revalidate
Running regression tests to make sure that the unchanged code still works and is not adversely affected by the new changes
Train
Inform users of the changes
Convert and release
Generate and release/install a new version with the modified parts
May involve migrating data at the same time
SEG Software Maintenance 19 19

20. Forward and reverse engineering and reengineering
“Forward Engineering is the traditional process of moving from high-level abstractions and logical, implementation-independent designs to the physical implementation of a system.”
“Reverse Engineering is the process of analyzing a subject system to identify the system’s components and their interrelationships and create representations of the system in another form or at a higher level of abstraction.”
“Reengineering ... is the examination and alteration of a subject system to reconstitute it in a new form and the subsequent implementation of the new form.”
— Chikofsky and Cross

21. Reverse engineering
In many legacy systems, the only reliable information about the system is the source code.
Reverse engineering reconstructs requirements, design models, test cases and user documentation consistent with the current state of the source code.
Reverse engineering encompasses several activities: program comprehension, software visualization, etc.
Reverse engineering is often the initial activity in a reengineering project.

22. System re-engineering
Re-structuring or re-writing part or all of a legacy system without changing its functionality.
Applicable where some but not all sub-systems of a larger system require frequent maintenance.
Re-engineering involves adding effort to make them easier to maintain. The system may be re-structured and re-documented.

23. Advantages of reengineering
Reduced risk
There is a high risk in new software development. There may be development problems, staffing problems and specification problems.
Reduced cost
The cost of re-engineering is often significantly less than the costs of developing new software.

24. Forward and re-engineering

25. The reengineering process
Reverse
engineering
Program
documentation
Data
re-engineering
Original data
structure
improvement
modularization
Structured
program
Re-engineered
data
Modularized
Original
Source code
translation
Sommerville, Ch. 21

26. Reengineering process activities
Source code translation
Convert code to a new language.
Reverse engineering
Analyze the program to understand it;
Program structure improvement
Restructure automatically for understandability;
Program modularization
Reorganize the program structure;
Data reengineering
Clean-up and restructure system data.
Sommerville, Ch. 21

27. Reengineering cost factors
The quality of the software to be reengineered.
The tool support available for reengineering.
The extent of the data conversion which is required.
The availability of expert staff for reengineering.
This can be a problem with old systems based on technology that is no longer widely used.

28. SEG4210 - Software Maintenance
Reverse Engineering Objectives
Recover lost information:
Changes made to the system are often undocumented;
This enlarges the gap between the design and the implementation
Reverse engineering techniques retrieve the lost information
SEG Software Maintenance 28 28

29. Reverse engineering

30. Reverse engineering Does not involve any adaptation of the system
similar to reconstruction of a blueprint
Design recovery: result is at higher level of abstraction
Redocumentation: result is at same level of abstraction

31. Reengineering (renovation)
Functionality does change
Then reverse engineering step is followed by a forward engineering step in which the changes are made

32. Legacy systems
For many systems, the software evolution process is not as straightforward as described.
Associated models and documentation of the software may be missing or hopelessly outdated.
The new requirements may not be anticipated by the design of the software, making the resulting changes difficult to implement correctly.
Legacy systems are old systems that have become significantly difficult to modify.
Accumulation of changes have eroded the modularity of the original design.
The documentation has not been maintained and has become obsolete.
One or more pieces of its underlying technologies have become obsolete.
Two complementary techniques are employed to support the continued evolution of legacy systems:
Reverse engineering.
Reengineering.

33. Obsolete system components
Hardware - may be obsolete mainframe hardware.
Support software - may rely on support software from suppliers who are no longer in business.
Application software - may be written in obsolete programming languages.
Application data - often incomplete and inconsistent.
Business processes - may be constrained by software structure and functionality.
Business policies and rules - may be implicit and embedded in the system software.

34. Legacy system evolution
Organisations that rely on legacy systems must choose a strategy for evolving these systems
Scrap the system completely and modify business processes so that it is no longer required;
Continue maintaining the system;
Transform the system by re-engineering to improve its maintainability;
Replace the system with a new system.
The strategy chosen should depend on the system quality and its business value.

35. Key points
Three types of maintenance are bug fixing, modifying software for a new environment and implementing new requirements.
For custom systems, maintenance costs usually exceed development costs.
Lehman’s Laws describe a number of insights into system evolution.

36. Key points
The process of evolution is driven by requests for changes from system stakeholders.
Software re-engineering is concerned with re-structuring and re-documenting software to make it easier to change.
The business value of a legacy system and its quality should determine the evolution strategy that is used.