Introduction to Software Evolution and Maintenance Importance of

Introduction to Software Evolution and Maintenance

Importance of evolution l l l 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”

Software change l 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. l A key problem for organizations is implementing and managing change to their existing software systems.

Software evolution and software maintenance l l 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 l l 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.

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 729 -1983 SEG 4210 - Software Maintenance 5

Types of changes Repair software faults • Changing a system to correct deficiencies in the way it meets its requirements. – corrective maintenance l 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 l “Reengineering” “Evolution” “Maintenance” l Add to or modify the system’s functionality • Modifying the system to satisfy new requirements. – perfective maintenance l Improve the program structure and system performance • Rewriting all or parts of the system to make it more efficient and maintainable.

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

Preventive Maintenance • Preventing failures by fixing defects in advance of failures • A kind of perfective maintenance • Key examples: Y 2 K and Daylight Savings adjustments SEG 4210 - Software Maintenance 8

Major causes of maintenance problems l Unstructured code l Insufficient domain knowledge l Insufficient documentation

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

Maintenance costs l l 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. ).

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

Lehman’s laws l l 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.

Lehman’s laws

The system evolution process Change requests Sommerville, Ch. 21 Impact analysis Release planning Change implementation Fault repair Platform adaptation System enhancement System release

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

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 4210 - Software Maintenance 17

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 4210 - Software Maintenance 18

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 4210 - Software Maintenance 19

Forward and reverse engineering and reengineering “Forward Engineering is the traditional process of moving from high-level abstractions and logical, implementationindependent 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

Reverse engineering l l 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.

System re-engineering l l l 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.

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

Forward and re-engineering

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

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

Reengineering cost factors l l 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.

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 4210 - Software Maintenance 28

Reverse engineering

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

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

Legacy systems l 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. l 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. l Two complementary techniques are employed to support the continued evolution of legacy systems: • Reverse engineering. • Reengineering.

Obsolete system components l l l 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.

Legacy system evolution l 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. l The strategy chosen should depend on the system quality and its business value.

Key points l l l 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.

Key points l l l The process of evolution is driven by requests for changes from system stakeholders. Software re-engineering is concerned with restructuring 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.