Evolution of Legacy Systems:

We consider there is a substantial difference between software maintenance and system evolution for reengineering perspective. Software maintenance is a fine-grained, short-term activity focused on a large number of localized changes. The Y2K problem, in most cases, is an example of pervasive localized software maintenance. With software maintenance, generally the structure of the system remains relatively constant and the changes produce few economic and strategic benefits.

We do system evolution which is a coarser grained, higher level, structural form of change that makes the software systems qualitatively easier to maintain. Our evolution approach allows the system to comply with broad new requirements and gain whole new capabilities. Our bottom-up and top-down approaches lead to substantive structural change in the system. In bottom-up approach we start with a detailed code review, and build up a new structure and a new form of documentation so that the system is qualitatively easier to maintain. In this approach architectural extraction techniques may also start with source code analysis. In our top-down approach we treat the software more as black boxes that can be reformulated for integration with other systems. This black-box approach is preferred to most clients because the technology for interfacing and integrating is developing much faster than the technology for program understanding.

One of the legacy evolution approaches known as the enterprise approach, we address the needs of the customer, the organization’s strategic goals and objectives, the operational context of the enterprise, as well as the current legacy systems and their operational environment. We recognize the central importance of both software engineering and systems engineering (and their interplay) to the system evolution initiative. We consider that program understanding is a prerequisite for software evolution. However, it is important to note that the nature of program understanding has already changed its emphasis from an understanding of the internals of software modules (white-box reengineering) to an understanding of the interfaces between software modules (black-box reengineering). Understanding is critical to our team's ability to evolve unproductive legacy assets (e.g., obsolete, overly constrained, or stagnating components) into reusable assets that can contribute to a product line approach. Client's legacy assets may be aging software systems that are constructed to run on various obsolescent hardware types, are programmed in obsolete languages, and suffer from the fragileness and brittleness that results from prolonged maintenance. As we shift the focus from program understanding to system understanding, from software maintenance to system evolution and migration, and from bottom-up techniques to top-down techniques, the prospects for widespread adoption improve. System understanding must be integrated with the other technologies, namely the Internet, distributed object technology, and net-centric computing.

1)   Distributed object technology (OT) approach: The cost/benefit ratio of this approach is staying the same in the face of new technologies such as CORBA, Java, and the Web. In the object-oriented model, systems are viewed as cooperating objects that encapsulate structure and behavior and that belong to hierarchically constructed classes. Distributed object computing (DOC) is the application of OT to distributed environments. Most of our DOC projects involve the use of middleware technology.

2)   Net-centric computing: The underlying principle behind NCC is a distributed environment where applications and data are downloaded from network servers on an as-needed basis. Thin clients may be traditional display-based terminals with no local processing. Or it may be a Java-based network computer (NC) that supports local processing. A third class of thin client is the Windows-based NetPC, which may also support Java.

From various studies the following are recommended for systems evolution:

• Understand the goals and resources of the enterprise with respect to a system evolution project.
• Understand the legacy system at a high level of abstraction using system understanding technology, paying particular attention to interfaces and abstractions. Find the encapsulatable components of the legacy system on which to build.
• Consider middleware and wrapping technologies for encapsulating subsystems and creating distributed objects. Apply those technologies in accordance with the framework.
• Consider using the Web for expanding the scope of the legacy system and as a development tool.