Software Maintenance Maintenance Is Inevitable Types of Maintenance

SoftWindows 8/18/2003

Software Maintenance

• Managing the processes of system change

Reverse Engineering (Software Maintenance & Reengineering) © SERG

Maintenance is Inevitable

• The system requirements are likely to change while the system is being developed because the environment is changing. • When a system is installed in an environment it changes that environment and therefore changes the system requirements.

Reverse Engineering (Software Maintenance & Reengineering) © SERG

Types of Maintenance

• Perfective maintenance – Changing a system to make it meet its requirements more effectively. • Adaptive maintenance – Changing a system to meet new requirements. • Corrective maintenance – Changing a system to correct deficiencies in the way meets its requirements.

Reverse Engineering (Software Maintenance & Reengineering) © SERG

Distributed Objects 1 SoftWindows 8/18/2003

Distribution of Maintenance Effort

Corrective maintenance (17%)

Adaptive maintenance Perfective (18%) maintenance (65%)

Reverse Engineering (Software Maintenance & Reengineering) © SERG

Evolving Systems

• It is usually more expensive to add functionality after a system has been developed rather than design this into the system: – Maintenance staff are often inexperienced and unfamiliar with the application domain. – Programs may be poorly structured and hard to understand. – Changes may introduce new faults as the complexity of the system makes impact assessment difficult. – The structure may be degraded due to continual change. – There may be no documentation available to describe the program.

Reverse Engineering (Software Maintenance & Reengineering) © SERG

The Maintenance Process

• Maintenance is triggered by change requests from customers or marketing requirements. • Changes are normally batched and implemented in a new release of the system. • Programs sometimes need to be repaired without a complete process iteration but this is dangerous as it leads to documentation and programs getting out of step.

Reverse Engineering (Software Maintenance & Reengineering) © SERG

Distributed Objects 2 SoftWindows 8/18/2003

System Documentation

• Requirements document • System architecture description • Program design documentation • Source code listings • Test plans and validation reports • System maintenance guide

Reverse Engineering (Software Maintenance & Reengineering) © SERG

Maintenance Costs

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

Reverse Engineering (Software Maintenance & Reengineering) © SERG

Maintenance Cost Factors

• Module independence – It should be possible to change one module without affecting others. • Programming language – High-level language programs are easier to maintain. • Programming style – Well-structured programs are easier to maintain. • Program validation and testing – Well-validated programs tend to require fewer changes due to corrective maintenance.

Reverse Engineering (Software Maintenance & Reengineering) © SERG

Distributed Objects 3 SoftWindows 8/18/2003

Maintenance Cost Factors (Cont’d) • Documentation – Good documentation makes programs easier to understand. • Configuration management – Good CM means that links between programs and their documentation are maintained. • Application domain – Maintenance is easier in mature and well-understood application domains. • Staff stability – Maintenance costs are reduced if the same staff are involved with them for some time. Reverse Engineering (Software Maintenance & Reengineering) © SERG

Maintenance Cost Factors (Cont’d)

• Program age – The older the program, the more expensive it is to maintain (usually) . • External environment – If a program is dependent on its external environment, it may have to be changed to reflect environmental changes. • Hardware stability – Programs designed for stable hardware will not require to change as the hardware changes.

Reverse Engineering (Software Maintenance & Reengineering) © SERG

Maintenance Measurements

• Control complexity: – Can be measured by examining the conditional statements in the program. • Data complexity: – Complexity of data structures and component interfaces. • Length of identifier names: – Longer names imply readability. • Program comments: – Perhaps more comments mean easier maintenance.

Reverse Engineering (Software Maintenance & Reengineering) © SERG

Distributed Objects 4 SoftWindows 8/18/2003

Maintenance Measurements (Cont’d) • Coupling: – How much use is made of other components or data structures • Degree of user interaction: – The more user I/O, the more likely the component is to require change. • Speed and space requirements: – Require tricky programming, harder to maintain.

Reverse Engineering (Software Maintenance & Reengineering) © SERG

Process Measurements

• Number of requests for corrective maintenance. • Average time taken to implement a change request. • Number of outstanding change requests. • If any or all of these is increasing, this may indicate a decline in maintainability.

Reverse Engineering (Software Maintenance & Reengineering) © SERG

Software Re-engineering

• Reorganising and modifying existing software systems to make them more maintainable.

Reverse Engineering (Software Maintenance & Reengineering) © SERG

Distributed Objects 5 SoftWindows 8/18/2003

When to Re-engineer

• When system changes are mostly confined to part of the system then re-engineer that part. • When hardware or software support becomes obsolete. • When tools to support re-structuring are available.

Reverse Engineering (Software Maintenance & Reengineering) © SERG

Re-engineering Advantages

• Reduced risk – There is a high risk in new software development. • Reduced cost – The cost of re-engineering is often significantly less than the costs of developing new software.

Reverse Engineering (Software Maintenance & Reengineering) © SERG

Re-engineering Cost Factors

• The quality of the software to be re- engineered. • The tool support available for reengineering. • The extent of the data conversion which is required. • The availability of expert staff for reengineering.

Reverse Engineering (Software Maintenance & Reengineering) © SERG

Distributed Objects 6 SoftWindows 8/18/2003

Source Code Translation

• Involves converting the code from one language (or language version) to another e.g., FORTRAN to C • May be necessary because of: – Hardware platform update – Staff skill shortages – Organizational policy changes • Only realistic if an automatic translator is available.

Reverse Engineering (Software Maintenance & Reengineering) © SERG

Reverse Engineering

• RE is the process of determining how a system works by analyzing its internal constituents and/or its external behavior. • In the software world one would say that RE is trying to figure out how a system works by: – Inspecting the source code and documentation (if it exists) – Exercising the executable programs and observing their behavior.

Reverse Engineering (Software Maintenance & Reengineering) © SERG

The Reverse Engineering Process

Program stucture Automated diagrams analysis System System to be Document Data stucture information re-engineered generation diagrams store Manual annotation Traceability matrices

Reverse Engineering (Software Maintenance & Reengineering) © SERG

Distributed Objects 7 SoftWindows 8/18/2003

Reverse Engineering

• Reverse engineering often precedes reengineering but is sometimes worthwhile in its own right – The design and specification of a system may be reverse engineered so that they can be an input to the requirements specification process for the system’s replacement. – The design and specification may be reverse engineered to support program maintenance.

Reverse Engineering (Software Maintenance & Reengineering) © SERG

Why is RE Important to Software Developers?

• Most software that is developed is not “from scratch”. • Understanding someone else’s source code, specifications, designs, is difficult. – Why is this so? – What makes software more difficult to understand than a toaster or a car?

Software Maintenance Problem

• A company hires a bright software developer to maintain a system. • The project manager points the developer to a source code directory and says “become an expert in the system as soon as possible”. • The IBM Tobey back-end compiler project allowed for a 1 year learning curve (but this is quite rare).

Distributed Objects 8 SoftWindows 8/18/2003

Program Structure Improvement

• Maintenance tends to corrupt the structure of a program. It becomes harder to understand. • The program may be automatically restructured to remove unconditional branches. • Conditions may be simplified to make them more readable.

Program Modularisation

• The process of re-organising a program so that related program parts are collected together in a single module. • Usually a manual process that is carried out by program inspection and re-organisation.

Recovering Data Abstractions • Many legacy systems use shared tables and global data to save memory space. • This causes problems because changes have a wide impact in the system. • Shared global data may be converted to objects: – Analyse common data areas to identify logical abstractions. – Create an object for these abstractions. – Find all data references and replace them with reference to the data abstraction.

Distributed Objects 9 SoftWindows 8/18/2003

Data Re-engineering

• Involves analysing and reorganising the data structures (and sometimes the data values) in a program. • May be part of the process of migrating from a file-based system to a DBMS-based system or changing from one DBMS to another. • Objective is to create a managed data environment.

Data Problems

• Data naming problems – Names may be hard to understand. The same data may have different names in different programs. • Field length problems – The same item may be assigned different lengths in different programs. • Hard-coded literals

Reverse Engineering Research

• The focus has been primarily on the development of tools to help software developers understand software quicker and with less effort. • Not much work has been done on RE methods, however.

Distributed Objects 10 SoftWindows 8/18/2003

Sherlock Holmes Analogy

• “We have developed good detective tools (e.g., magnifying glasses, fingerprint matchers, etc) but we have little insight on how to train someone to be good detective. (e.g., guidelines, processes, etc)” S. Mancoridis

Progress Has Been Made In …

• Source code analysis • Program tracing and profiling • Automatic modularization (software clustering)

But still a research area in its infancy …

Distributed Objects 11