Software Maintenance1.All activities done after S\w becomes operational 2. Life time activity of S\W . 3.

May range from 15-20 years where as development of SAME S/w might have taken 2 years. NEED FOR MENTAINANCE Error, changes, enhancement, complexity. Depending upon above needs maintenance can be categorized as CORRECTIVE MENTAINANCE (21 %) Occurs in response to the system failures that are caused by error. Requires action like S/W restoration by correcting errors. ADAPTIVE MENTAINANCE (25 %) in response to

policy change- income tax rule, ban rate, currency change new technology new OS, new compiler

PERFECTIVE MENTAINANCE(50 %)

improving efficiency enhancement\deletion to make product better, faster, well documented, cleaner structure

OTHER TYPES OF MENTAINANCE Corrective, adaptive, perfective maintenance leave the program complex. Other type of maintenance refers to reduction or controlling effect of these complexities.

Code restructuring Code optimization is modifying the codeto make it run faster or utilize the resourese more effectively. Re documentation

Only 4% as client is rarely concerned with it. PROBLEMS DURING MENTANANCE Program written by one person and maintained by other in isolation over when a person leaves the organization. Program changed by person who did not understand it clearly resulting in deterioration Poor listing. When there is poor flow of reading the program. Like a good listing will tell that from this component 3 go to component no5 listed on page 11. Or to page no2. Lack of stating their own needs of the user when S\w is run over a period of time When maintainability of the S\w is low. Rigid architecture.

MENTAINANCE IS MANGEABLE It is not necessarily an ad hoc activity. Studies shows that maintenance efforts are usually distributed into Emergency debugging, routine debugging, environment adaptation, enhancement by user, better documentation need and efficiency improvement.
-

Except for emergency debugging routine the rest can be scheduled properly. Only emergency debugging is situation dependent and cannot be scheduled.

SOLUTIONS OF MENTAINANCE PROBLEMS BUDGET AND EFFORT REALLOCATION More time and resources should be inserted in the development specification and design to more maintainable systems rather than unmentionable systems. In short more maintainable systems should be

developed using advanced requirement specification approachable, design techniques and tools quality, quality assurance procedures etc. COMPLETE REPLACEMENT OF THE SYSTEM
-

After a lot of understanding if it comes out that the cost of maintenance is much more than the cost of developing a new maintainable system their complete replacement with a new system is suggested. However it comes at a greater risk and does not give full guarantee.

MAINTANANCE OF THE EXISTING SYSTEM

-

Making the current system to have potential to evolve to a higher scale provided more sophisticated user driven functionality and integration it with other system in a \cost effective manner RIPPLE EFFECT

Same as in progress the modification in one component affect the modification in other. The functional and other component can change and stability (resistance to the amplification of the change.

1. Maintenance Objective(whether corrective, adaptive or perfective is to be done) 2. Program Understanding ( to understand complexity, documentation, and self-description) 3. Generate maintenance proposal i.e how the maintenance activity will proceed.If the program can support extension of critical function the proposal is easier to write 4. Consider ripple effect. Correction made in one component of the software might ripple down to other component and needs to be addressed. 5. Software is tested and if it does not pass the test, steps from step 1 onwards are repeated.

MAINTENANCE MODELS

1. QUICK FIX MODEL Ad-hoc approach Done without detail analysis of long term effects like ripple effects. Can be used for small projects where development and maintenance is done by the same person who can understand the project even without detailed documentation. Less time consuming for small projects and can satisfy urgent demand of the client. Unrealistic for even medium size project and long term upgrades.

2. ITERATIVE ENHANCEMENT MODEL Iterative enhance model of development is applied to maintenance. Three stages of this model are Analysis of existing system Characterization of proposed modification Redesign and implementation.

Assumes that complete documentation of each phase of SDLC of the system is available . The modification of the highest level documentation(rather than fixing the error immediately) that is affect by the proposed change is the starting point. Therest of the documentation and design is modified removing the ripple effect. Uses other models like quick fix .

3. REUSE ENHANCEMENT MODEL

Reusable components are identified. The remaining parts are analyzed and understood.

The above parts are modified according to new requirement Modified parts are integrated into new system

4.BOHEMS MODEL Based on Economics model Management decisions of maintenance are made after applying cost benefit evaluations to a set of proposed changes. The approved changes are allocated their own budget and resources. Maintenance manager has to balance the maintenance objectives with environmental constraint. Changes are implemented New software is used Evaluation is done. New changes can be proposed that can restart the cycle.

6. TAUTE MAINTENANCE MODEL Consists of 8 phases. Change Request phase-initiated by client and categorized(corrective, adaptive etc.) by maintenance manager Estimate Phase -Estimates time and resources required to make the changes. Impact of ripple effect caused by the changes is also studied. Schedule Phase-Identify change request for the next scheduled release. Programming Phase Source code modification is performed. Test Phase- Regression testing is done Documentation Phase-System and user documentation of the new system is done. Release phase- New software along with updated documentation is delivered to the client. Acceptance testing is performed.

Operation Phase S/W is used and if new problems or new requirements arise we start with change request phase.

Reverse Engineering
When the program is unstructured and without or bad documentation it is difficult to understand and hence maintain it. Reverse engineering is the process of finding difficult, unknown and hidden information from the existing system in order to understand it. Thus understanding the program is its main scope. The areas where reverse engineering is applicable include the following: 1. Program comprehension .i.e finding out the problem from given system which may not be clear. 2. Re documentation or documentation 3. Recovery of design at any level of abstraction 4. Identifying reusable components 5. Identifying components that need restructuring 6. Recovering business rules 7. Understanding high level system description Activities like re design re structuring and enhancement are not part of reverse engineering but maintenance. The task performed in reverse engineering in order to understand the S/W are 1. Mapping between application and program domains: Usually the program does not mention the original problem statement for which it was designed. It is essential to map (that is find out ) the problem from the given system. 2. Mapping between abstract levels to concrete level is finding out the abstract requirement (from highest level) from lower level requirement corresponding to modular codes. 3. Rediscovering higher level structure: Due to various changes in the S/W due to maintenance activities (bug fixing) the original structure is lost. This original structure needs to be rediscovered in order to find the original purpose that has been lost due to changes.

4. Finding missing links between syntax and semantic: From the changed syntax we try to establish the semantic for which the changes must have been made. 5. To extract reusable component: Finding and using the reusable components (that can be used in requested changes without modification) saves time and increases Levels of Re- engineering Re- Documentation. If the product is not necessarily at higher level than the original system re documentation is performed. Its objective are To create alternative view of the program say by new data flow diagram or control flow graph that gives a better understanding of the system. To improve current document that should have been generated earlier during original development activity. To generate documentation for the newly modified program.

Design Recovery If the maintenance requires a major change in the requirements or a lot of correction is needed the maintenance engineer has to perform design recovery along with specification re recovery. Design recovery is performed by maintenance engineers who have knowledge of problem domain and application domain. The recovered design may be used for further improvement or development of similar projects (total replacement)

Specification

Redocumentation

Specification Recovery

Design

Redocumentation Design Recovery

Implmentation

Redocumentation

SOFTWARE RE-ENGINEERING
Legacy system Legacy systems are those systems that may have been best in the past using the technology available at that time. But in due course of time, as the requirements changed and maintenance activities like bug fixing , enhancement deletion and re documentation took place so that these system become unmanageable and expensive to maintain These systems may be poorly understood in present context due to poor structure and documentation. Software re-engineering is concerned with taking existing legacy system and re-implenting them to a more manageable maintainable reengineered system. Thus re-engineering takes old system as a specification for new system , understood and translate the source code to a new language, restructure old code, transfer to new platform like client server architecture and re documentation. While modifying legacy system it is suggested that following focus points must be considered Concentrate on overall control flow first to understand the problem Study code well before overall attempt of changing Heavily comment internal code Create cross references Build system tables

Use new variables, constants and declarations to localize the effect of change Keep detailed maintenance document ( where and how the changes have been made) Use new design techniques.

The source code translation to a new language may be initiated by (i) hardware update in which original language compilers are not compatible. (ii) Staff trained in original language might have left and there is severe lack of people skilled in old language.(iii) Organization adopts a standard language to minimize software cost of keeping different language support.

Program restructuring transforms a system from one representational to another form or a better representation. This could done for better readability of the program. There can also be restructuring of the functions using better constructs ( switch case in place of multiple ifs) or algorithm that enhances the efficiency. How ever if the re engineering of legacy system is not cost effective developing the system from the scratch is most viable option. It will consider system specification as the start point rather than any old system.