An application has served the business needs of a company for 10 or 15 years. During that time it has been corrected, adapted and enhanced many times. If the application is unstable because but every time a change is attempted, unexpected and serious side effects will occur.
Un-maintainable software is not a new problem. In fact, a software maintenance team has generated the broadening emphasis on software reengineering.
Software Re-engineering Process Model
Re-engineering takes time; it costs significant amounts of money; and it absorbs resources that might be otherwise occupied on immediate concerns. For all of this reason, Reengineering of information systems is an activity that will absorb information technology resources for many years. That’s why every organization needs a practical strategy for software reengineering.
Reengineering is a rebuilding activity, and we can better understand the reengineering of information systems if we consider an analogous activity; the rebuilding of a house. Consider the following situation; if you purchased a house in another state. You are never actually seen the property, but you acquired it at an reasonable low price, with the warning that it might have to be completely rebuilt. How would you proceed ?
- Before you can start rebuilding, it would seem reasonable to inspect the house. To determine whether it is in need of rebuilding, you would create a list of criteria so that your inspection would be systematic.
- Before you tear down and rebuilt the entire house, be sure that the structure is weak. If the house is structurally sound, it may be possible to “remodel” without rebuilding.
- Before you start rebuilding be sure you understand how the original was built. Take a peek behind the walls. Understand the wiring, the plumbing, and the structural internals. Even if you trash them all, the insight you will gain will serve you well when you start construction.
- If you begin to rebuild, use only the most modern, long-lasting materials. This may cost a bit more now, but it will help you to avoid expensive and time-consuming maintenance later.
- If you decide to rebuild, be disciplined about it. Use practices that will result in high quality-today and in the future.
These principles focus on the rebuilding of a house, they apply equally well to the reengineering of computer-based systems and applications.
To implement these principles, we apply software reengineering process model that defines size activities. In some cases, these activities occur in a linear sequence, but this is not always the case. For e.g., it may be that reverse engineering may have to occur before document restricting can commence.
This reengineering paradigm show in figure is a cyclical model. This means that each of the activities presented as a part of the paradigm may be revised. For any particular cycle, the process can terminate after any one of these activities.
Every software organization should have an inventory of all applications. The inventory can be nothing more than a spreadsheet model containing information that provides a detailed description of every active applications by storing the information according to business critically, longevity, current maintainability, and other locally important criteria, candidates for reengineering work.
It is important to note that the inventory should be revisited on a regular cycle. The status of applications can change as a function of time, and as a result, priorities for reengineering will shift.
Weak documentation is the trademark of many legacy system. But what do we about it? What are our options?
- Creating documentation is too time consuming. If the system works, we will live with what we have. In some cases, this is correct approach. It is not possible to re-create documentation for hundreds of computer programs. If a program is relatively static, is coming to the end of its useful life, and is unlikely to undergo significant change.
- Documentation must be updated, but we have limited resources. We will use a “document when touched” approach. It may not be necessary to fully re-document an application. Rather, those portions of the system that are currently undergoing change are fully documented. Over time, a collection of useful and relevant documentation will evolve.
- The system is business critical and must be fully re documented. Even in this case, an intelligent approach is to pare documentation to an essential minimum.
A software of organization must choose the one that is most appropriate for each case.
The term reverse engineering has it origins in the hardware world. A company disassembles a competitive hardware product in an effort to understand its competitor’s design and manufacturing “secrets”. These secrets could be easily understood if the competitor’s design and manufacturing specifications were obtained.
But these documents are proprietary and unavailable to the company doing the reverse engineering in essence, successfully derives one or more design and manufacturing specifications for a product by examining actually specimens of the product.
Reverse Engineering for software is quite similar in most cases, however, the program to be reverse engineered is not a competitors. Rather, it is the company’s own work. The ‘secrets’ to be understood are obscure because no specification was ever developed. Therefore, reverse engineering for software is the process of analyzing a program in an effort to create a representation of the program at a higher level of obstruction than source code. Reverse engineering is a process of design recovery. Reverse engineering tools extract data, architectural, and procedural design information from an existing program.
The common type of reengineering is code restructuring. Some legacy systems have a relatively solid program architecture, but individual modules were coded in a way that makes them difficult to understand, test, and maintain, In such cases, the code within the suspect modules can be restructured.
To accomplish this activity, the source code is analyzed using are structuring tool, violations of structured programming constructs are noted and code is then restructured. The resultant restructured code is reviewed and tested to ensure that no anomalies have been introduced, internal code documentation is updated.
A program with weak data architecture will be difficult to adapt and enhance. In fact, for many applications, data architecture has more to do with the long-term viability of a program that the source code itself.
Unlike code-restructuring, which occurs at a relatively low level of abstraction, data structuring is a full-scale reengineering activity. In most cases, data restructuring begins with are reverse engineering activity. Current data architecture is dissected and necessary data modules are defined. Data object and attributes are identified, and existing data structures are reviewed for quality.
In an ideal word, applications should be rebuilt using a automated ‘reengineering engine’. The old program would be fed into the engine, analyzed, restructured and then regenerated in a form that exhibited the best aspects of software quality. In the short term, it is unlikely that such an ‘engine’ will appear, nut CASE vendors have introduced told shat provide a limited subset of these capabilities that addresses specific application domain. More important these capabilities that addresses specific application domain. More important these reengineering tools are becoming increasingly more sophisticated.