|
Legacy / Mainframe Systems:
Evolving over a number of years, Legacy / Mainframe systems embody substantial corporate knowledge, including requirements, design decisions, and business rules.
In order to effectively use these assets, it is important to develop a systematic strategy for the continued evolution of currently fielded systems to meet changing mission, technology and user needs. However, knowledge of the business rules and technical decisions is often embedded in the code. Such knowledge is difficult to recover after many years of operation, evolution, and personnel change. The software portion of a Legacy / Mainframe system may have been written in the past 25 years, developed using (what may now be viewed as) archaic and ad-hoc methodologies, and subjected to prolonged and sometimes dramatic (even traumatic) maintenance. The result is a Legacy / Mainframe system that lacks the ability to evolve to meet ever-changing demands in a cost-effective manner.
The Biggest Challenge:
The biggest challenge for a large Legacy / Mainframe system to Maintain and improve for a greater return on Investment. This gives the scope for a systematic approach for re-engineering and Maintenance of Legacy / Mainframe system.
Maintenance Activities:
Based on the Purpose of maintenance, maintenance activities can broadly be classified as :
1.Corrective Maintenance: This is to correct the fault of the software that either escaped during development or testing of the system or that have been introduced during previous maintenance activities.
2.Performance Maintenance: This focuses on improving software attributes such as performance, memory usage, and documentation.
3. Adaptive Maintenance: which addresses new requirements (enhancement) or new platforms (such as a porting to a new database).
Maintenance Process Involves:
The steps involved for the maintenance activities:
1. Understanding the existing code (program comprehension)
2. Determining where to make changes
3. Assessing impact of changes (impact analysis)
4. Rebuilding code after changes
5. Regression testing to validate changes
Researchers have established that the program comprehension takes around 40 to 90 percent time of the maintenance activity. Program comprehension for maintenance relies on the artifacts left from earlier activities (requirements specifications, design documents, source code, tests, and records of previous maintenance). Frequently, the reliability of these sources of information is suspecting; thus the often-heard lament that maintainers can only trust the source codes. The software maintainer must attempt to reconstruct not only a cognitive model of the system as it exists, but must also frequently determine why it exists in the current state.
Program comprehension is important for development tasks as well. Tasks such as isolating bugs during testing, performing code reviews, and integrating with other software require developers to apply program comprehension skills in development settings. In addition, few development projects complete without personnel turnover which requires that new personnel learn, extend, and modify the code developed by previous personnel.
In order to facilitate this maintenance activity, a systematic approach is needed to be followed which will take the system towards maturity and help in achieving Most of the quality and Managerial Goals (Refer Appendix).
Systematic Approach:
1. Defining the architecture of the system:
The goal of architectural extraction is the definition of the architectural level Components, Connections, constraints and associated rationale that describe the specific system. This includes all necessary view of the system. That is there should be a etc. Each of these views may require a sub view as the system is a large system. Once the architecture of the existing Legacy / Mainframe system has been extracted and documented it now becomes a major instrument to be used during the maintenance of this system. It results in the creation of set of specific documents defining the necessary view and in the identification of the major software components, and rules concerning interactions.
2. Identifying the common Reusable Components
During the extraction of architecture of a Legacy / Mainframe system, it is needed to identify the common rules and the components. This helps in a great extent to reduce the effort for the maintenance.
3.Common Guidelines for maintenance:
Formulating a common guidelines to solve the maintenance problems
Conclusion:
The Legacy / Mainframe systems mainly deals with lot of data and mush of their data stored in the flat files. The requirements are ever growing with a need for a system which is reliable and cost effective. Along with this the requirement is to have a faster retrieval of correct data. This has given rise to the database concept and the Internet. The maintenance needs are to satisfy these ever growing need of software system. The cost of incremental change to a Legacy / Mainframe system needs to be reduced. Criteria for deciding on the need for reengineering range from heuristics such as age of code and excessive maintenance personnel training cost to parameterize cost models. Improvement in this cost is anticipated by investing more than the minimal amount into reacting the requested change. The additional investment would go into improving the way the system has been engineered with the result of smaller incremental cost in the future. |
