inconsistent. While you may intend to document the change in the requirements and design, additional emergency fixes to the software may then be needed. These take priority over documentation. Eventually, the original change is forgotten and the system documentation and code never become consistent. Figure 8.6: The emergency repair process System re-engineering Software re-engineering is concerned with re-implementing legacy systems to make them more maintainable. Re-engineering may involve re-documenting the system, organising and restructuring the system, translating the system to a more modern programming language, and modifying and updating the structure and values of the system’s data. The functionality of the software is not changed and, normally, the system architecture also remains the same. Re-engineering a software system has two key advantages over more radical approaches to system evolution: 1. There is a high risk in re-developing business-critical software. Errors may be Reduced risk: made in the system specification, or there may be development problems. Delays in introducing the new software may mean that business is lost and extra costs are incurred. 2. Reduced cost: The cost of re-engineering is significantly less than the cost of developing new software Figure 8.7: Forward engineering and re-engineering Forward engineering starts with a system specification and involves the design and implementation of a new system. Re-engineering starts with an existing system and the development process for the replacement is based on understanding and transforming the original system. Figure 8.8: The reengineering process Figure above illustrates the re-engineering process. The input to the process is a legacy program and the output is a structured, modularised version of the same program. During program the data for the system may also be reengineered. The activities in this re-engineering process are:
inconsistent. While you may intend to document the change in the requirements and design, additional emergency fixes to the software may then be needed. These take priority over documentation. Eventually, the original change is forgotten and the system documentation and code never become consistent. Figure 8.6: The emergency repair process System re-engineering Software re-engineering is concerned with re-implementing legacy systems to make them more maintainable. Re-engineering may involve re-documenting the system, organising and restructuring the system, translating the system to a more modern programming language, and modifying and updating the structure and values of the system’s data. The functionality of the software is not changed and, normally, the system architecture also remains the same. Re-engineering a software system has two key advantages over more radical approaches to system evolution: 1. Reduced risk: There is a high risk in re-developing business-critical software. Errors may be made in the system specification, or there may be development problems. Delays in introducing the new software may mean that business is lost and extra costs are incurred. 2. Reduced cost: The cost of re-engineering is significantly less than the cost of developing new software Figure 8.7: Forward engineering and re-engineering Forward engineering starts with a system specification and involves the design and implementation of a new system. Re-engineering starts with an existing system and the development process for the replacement is based on understanding and transforming the original system. Figure 8.8: The reengineering process Figure above illustrates the re-engineering process. The input to the process is a legacy program and the output is a structured, modularised version of the same program. During program the data for the system may also be reengineered. The activities in this re-engineering process are:
10IS51_NOTES.docx