# INTRODUCTION oftware engineering is a topic of importance in the age of software and is gaining attention. It is developing fast area and not existing from centuries. Software maintenance and software reengineering both fall in the ambit of software engineering. Both terms came from the real hard ware objects. These are more suited to software systems and software objects as these do not wear or tear out like real world physical objects. These two terms are yet young and developing. There is not clear cut line between them. These terms are mingled and the people are using them interchangeably. One is the problem in the developing the subject matter of the other. Now software is gaining importance in every sphere of life and these two are very closely associated to software system life cycle. It is time to differentiate the two and promote the subject matter of these two concepts. # II. # SOFTWARE MAINTENANCE Software maintenance is one of the stages in the software development life cycle. It starts after the deployment of software in the working field. It is to remove the defects and deficiencies which encounters while starts actually working in the field. According to IEEE Std. 610.12 [7] 'Software maintenance is the process of modifying a software system or component after delivery to correct faults, improve performances or other attributes, or adapt to a changed environment'. a) Nature and Scope of Maintenance Software maintenance has good scope in future times. In the world of fast changes, maintenance expertise will gain more importance which can sustain the working of software systems. Maintenance means modifying software system or a component of the software system to make it working on the platform and adapt to the minor changes in the requirements, environment or technology. Every system needs maintenance for the whole life period. Maintenance is preservation of the legacy software system. Many surveys have shown that software maintenance can account for 60 to 80 percent of the cost of total life cycle of software product. According to Erlikh more than 90 % of the total cost of software goes to maintenance and evolution of the software product [1]. According to Lientz and Swanson many organizations were spending 20% to 70% of their computing efforts on maintenance [8]. Software maintenance is of following four types # Corrective maintenance: As its name implies, activities of correcting bugs in the software are included in this type of maintenance. It is for making the software system to conform to the real situation. # Adaptive Maintenance It deals with making the software adjustable to the changed environment # Preventive Maintenance Modification of the software to detect and correct hidden faults (bugs) before becoming active. This paper will help the software managers to recognize and make the best use of these two terminologies for right treatment of software systems. # Perfective maintenance It is modification of the software for better performance, maintenance and reliability. The activities related to updating the software are included in this type of maintenance. The efforts (cost) distributions for these four types of maintenance are as under ? Corrective maintenance 21% ? Adaptive Maintenance 25% ? Preventive Maintenance 4% ? Perfective maintenance 50% [6]. It is suggested from the above figure that perfective maintenance consumes major part of cost estimation. Preventive maintenance is not taken to any significant level in software industry. Software maintenance and reengineering are hot topics in theses days. Software managers use these two interchangeably. It is time to differentiate maintenance and reengineering in software industry. Software maintenance is last stage in the software development life cycle. Maintenance starts after the delivery of the software. The ability to accurately estimate the time and cost of software maintenance is the key factor for successful of maintenance project. Software maintenance starts after delivery of the software system. It goes on increasing with the increasing age of software as depicted in the following figure 1. Figure 1 Accumulated affects of maintenance makes the system complex and deteriorate the system's architecture. Software system goes on aging with time and maintenance cost increases. When maintenance cost is too much high or difficult to maintain, it means system is to retire. Then reengineering is solution at this point. Reengineered software starts working with normal maintenance for another life span. Reengineering should be done at right time. If we overlook this time, reengineering will be costly or even not feasible and then we have to throw the costly legacy software under utilized. III. # REENGINEERING Reengineering is the analysis of existing software system and modifying it to constitute into a new form. Chikofsky and Cross define reengineering as 'the examination and alteration of a subject system to reconstitute it in a new form and subsequent implementation of that form' [9]. According to IEEE Std. 1998 'A systemchanging activity that results in creating a new system that either retains or does not retain the individuality of the initial system' [10]. a) Nature and Scope of Reengineering When maintenance cost is not feasible, we go for reengineering the software system. Reengineering makes the software system new. Reengineering has the following three stages. # Reverse engineering 2. Architecture transformations 3. Forward engineering # Reverse engineering In this stage software is thoroughly understood. It is untied and underlying technology is perceived. Business process is improved and requirements are updated. Objects are added or deleted according to the new system planned. In this stage we go from code level to higher level abstraction. # Forward engineering In this stage, we move from higher level of abstraction to code level. In this stage software integrated according to new design. It is vertically downward step as shown in the fig. 2. Figure 2 In the above figure, updation of user's requirements and improvement in architecture of software is done in transformation phase. We can express reengineering by the following equation. # Reengineering = Reverse engineering + ? + forward engineering The symbol in the above equation represents the enhancement and design change. In the coming future, reengineering can solve the problem of software backlogs and it can lower the software investment in organizations. Reengineering can increase the software age. Point T is the transition state from maintenance to reengineering zone. Transition state is new term defined by the author of this paper. It is the state in the life of software when reengineering is best possible with optimal cost. Software system is candidate for maintenance in the first zone and candidate for reengineering in the second zone. Maintenance phase is always first and reengineering phase starts after maintenance phase. When maintenance exhausts, reengineering phase is ready to serve the software system. Both zones are separated by red point T and must not overlap each other. Figure 3 Maintenance increases the age of the software and reengineering gave a fresh age period to software system. T is the transition point, beyond point T; it is not feasible to maintain the system. System should be reengineered at the point T. Reengineering cost will be optimal at the critical point T. If we do not reengineering the System at T and go on maintaining the software with high cost, reengineering zone will be exhausted and reengineering is not possible with feasible cost. Then there is no other option than to throw the legacy software and purchase costly new one. Legacy software will be added to the backlog of wasted software. Maintenance phase keeps the software up to date with environment changes and changing user requirements. Reengineering will give another life span to software with normal maintenance. # b) Cost based Model Following figure 4 depicts the graph of maintenance cost and reengineering cost of Software system. Maintenance cost starts from the point O (Origin) and goes on increasing with time. It starts increasing rapidly from point T because software completes ten years, the normal age of the software. According to literature, software age is seven years for structured systems and ten years for object-oriented software systems. Reengineering cost is all most same up to point T because software is within age at the point T. After point T reengineering cost also starts increasing but with normal rate but maintenance cost increases at high rate. This happens because maintenance zone is over and the software is in reengineering zone beyond point T. Maintenance cost and reengineering cost are equal at the point T as depicted in the figure 4. If both the costs are equal then we must go for reengineer. Reengineering will make the system new on the new platform with new design. Reengineering of the system is needed to bring down the maintenance cost. At this point we think of reengineering or retiring the software. If we retire the system then we have to bear the cost of new software. Cost of new software is much high than the cost of reengineering. Figure 4 If we do not reengineering the software system at point T, maintenance cost will increase sharply (as shown in the figure 4) it will be difficult to maintain the system at such a high cost. Maintenance after the point T increases the complexity of the system and decreases the quality of software where as reengineering improves the quality of the software, controls the maintenance cost and increases the life span of the software system. The software system is old at the point T and high maintenance cost is required. It is difficult to maintain the system with such a high maintenance cost. At this point system should be reengineered or retired. If we reengineer the software at this point, Reengineering cost will be lowest (optimal). Reengineered Software will be new one with another life span and Maintenance cost will be ordinary. # c) Object based Model This is object based model for differentiation of maintenance and reengineering. Maintenance is done to make the faulty object fine. As the system ages, software architecture deteriorate with ripple effects of maintenance. System object becomes faulty and maintenance makes it fine. The number of faulty objects increases with time and maintenance becomes difficult. Then what to Do? Software should be reengineered but when? This is the question. It is to be determined on the basis of the faulty objects. In this work, object is seen at a higher level of abstraction and is taken as conceptual module that can be plugged in and plugged out from the software system. Reengineering identifies reusable components (objects) and analyzes the changes that would be needed to regenerate them for reuse within new software architecture. The use of a repeatable, clearly defined and well understood software objects, has make reengineering more effective and reduced the cost of reengineering. Maintenance and reengineering will be separated on the basis of faulty objects. The object oriented approach attempts to manage the complexity inherent in the real world problems by abstracting out knowledge and encapsulating it [2]. Object is an instance of a class and has an identity and stores attribute values [3]. All objects of the candidate software system are untied (Reverse engineering). Faulty objects are indentified and modified. Then redesigning of the structure (transformation of the architecture) of the system according to new modern design is done. Then according to new design objects are integrated (Forward Engineering). Abstraction is good tool for reengineering object oriented design as it helps in reducing complexity. Large systems are complex having more objects as each additional object increases the complexity of the system [4]. Reengineering of software system is accomplished by reengineering the faulty objects in the system. Software system is untied, objects are identified for reengineering. Identified objects for reengineering are called faulty objects. Faulty objects are reengineered independently and made Fine objects, software architecture is changed, and all the objects (now all objects are fine) are integrated according to the new architecture. Fine object is an object which conforms to our requirements and functions well in the system. As software ages some objects becomes faulty. Faulty object is an object which does not conform to our requirements and does not function well with in the system. We go on maintaining the faulty objects to maintain the software system. With maintenance of the faulty objects again and again, architecture of the software deteriorates. We reach at a point where reengineering of the system is needed. But what is that point? Let us suppose there are N objects in system which is our candidate system. Let it be O1, O 2 , O 3 ,?????..O N . Go on maintaining the software till half of the objects are not faulty. When half of the objects (N/2) are faulty in your application go for reengineering the software. The reengineering cost of the candidate system with N/2 faulty objects will be one forth (25%) of the new development cost [5]. This is the optimal cost according to the research paper 'Cost of Reengineering (Object-Oriented Software Systems) versus Developing new One-A Comparison' by the same author. Hence you reach the stage where reengineering starts. When N/2 or more objects are faulty (System with N objects) stop maintenance and reengineer software system. When N/2 objects become faulty; it is a transitional state from maintenance to reengineering. This is vital stage in the software life span for transition from maintenance to reengineering. If the software managers pay no heed to this transitional stage and go V. # SUMMARY AND CONCLUSIONS In this piece of work four models are presented for differentiation in maintenance and reengineering as under These models are valuable to software managers for reengineering the software systems at the right time. Reengineering is not feasible before and after the transition state. These models will help to reengineering the software and escape the burden of purchasing costly new software. Software investment expenditure curve will fall in the organizations. There will be full utilization of the software and software backlog will be decreased. ![It is vertically upward step shown in the fig. 2 Architecture transformations Software architecture is changed. It is modified, improved to fit in the new technology and new environment. It is the architecture designing stage. It is horizontally right ward step as shown in the figure 2](image-2.png "") ![IV. MAINTENANCE VS. REENGINEERING Maintenance and reengineering are closely related to each other. Software maintenance starts after delivery of the software to correct faults, to improve performance and other attributes of the software. Maintenance plays an important role in the life cycle of a software system. Maintenance is the last stage of the software development life cycle. When maintenance exhaust, reengineering is called. Maintenance problems are a driving force behind re-engineering. Reengineering is the only way to avoid new development cost. Following are the models for diversification of maintenance and reengineering. a) Thoroughfare model According to this model, life span (age) of software system is divided into two zones as depicted in figure 3. Software life span is from point A to point B.](image-3.png "") 2![Cost comparison model 3. Object based model 4. Discrete model](image-4.png "1. Thoroughfare differentiation model 2 .") 1Maintenance vs. Reengineering Software Systems2011December62on maintaining with high cost, it means they areoverlapping the reengineering zone. It this way, they willstrike in a situation when reengineering is not feasible.The cost of reengineering is very much high or equal tothe new development. Then they will have to retire thelegacy software. It will be financial loss to theorganization as more investment on software is neededto purchase new software.© 2011 Global Journals Inc. (US) © 2011 Global Journals Inc. (US) Global Journal of Computer Science and Technology Volume XI Issue XXIII Version I 59 2011 December © 2011 Global Journals Inc. (US) Global Journal of Computer Science and Technology Volume XI Issue XXIII Version I 60 2011 December Maintenance vs. Reengineering Software Systems © 2011 Global Journals Inc. (US) DecemberMaintenance vs. Reengineering Software Systems © 2011 Global Journals Inc. (US) Global Journal of Computer Science and Technology Volume XI Issue XXIII Version I 63 2011 December Maintenance vs. Reengineering Software Systems © 2011 Global Journals Inc. (US) Global Journal of Computer Science and Technology Volume XI Issue XXIII Version I DecemberMaintenance vs. Reengineering Software Systems In this work three new terms 'Transition state', 'Reengineering Zone' and 'Maintenance Zone' are coined and added to reengineering subject matter. ## VI. ## FUTURE WORKS TO BE DONE These given Models are new in the field of Reengineering of object oriented software systems. The future work is to test these models for suitability to fit on the basis of analysis of current and past data. These models can be accepted as it is or improved or rejected. Once fit and fine these models will help in reengineering the legacy software with optimal cost. This work will be beneficial to the both communities, the software managers and the software engineers. Software managers can order for reengineering at transitional point where maintenance zone ends and reengineering zone starts. * Leveraging legacy system dollars for Ebusiness LErlikh 200 IEEE) IT Pro. Retrieved 24-02-2011 from * Designing Object-Oriented Software R WBrock BWilkerson LWiener 2007 Prentice-Hall of India 5 New Delhi * BerndBruegge DutoitAllen H Object-Oriented Software Engineering Using UML, Patterns, and Java Singapore Pearson Education 2004 724 * Object-Oriented Software Engineering SHalladay MWiebel BPB Publications 35 New Delhi * Cost of Reengineering (Object-Oriented Software Systems) versus Developing new One-A Comparison' Research paper GillBakhshish Singh Serials Publication New Delhi * Software Reengineering RobertSArnold 1993 IEEE Computer Society Press Los 60 Alamitos, California * Standard Glossary of Software Engineering Terminology IEEE Std. 610.12 1990 IEEE Computer Society Press Los Alamitos, CA * Software Maintenance Management Lientz ESwanson 1980 Addison-Wesley * Reverse Engineering and Design Recovery: A Taxonomy EChikofsky JHCross IEEE Software Engineering journal Jan. 1990 * IEEE Std 1219-1998 IEEE Standards Software Engineering IEEE Press 1999 Two Process Standards * Successful Software Reengineering SalValenti 2002 IRM Press 1331 E., Chocolate Avenue, Hershey * Software Reengineering RobertSArnold 1994 IEEE Computer Society Press Los Alamitos, California * Software engineering RogerSPressman 1992 McGraw-Hill New York 3 rd ed. * Object Oriented Analysis and Design with Applications GradyBooch 2003 Pearson Education Singapore * Software Engineering Ian Sommerville 1994 Addison-Wesley Publishing Company Singapore * New age International KKAggarwal YogeshSingh 2002 P) Ltd., Publishers New Delhi Software engineering * Gill Nasib Singh Software Engineering: software reliability, Testing and Quality Assurance New Delhi Khanna Book Publishing Co.(P) Ltd 2002 * An Integrated Approach to Software Engineering PJalote 1996 Narosa Publishing House New Delhi