The Delta Insurance Company is having a policyholder subsystem which has started giving trouble.
Over the years, the application evolved from using fixed length, multi-record type files to using a hierarchic database to using a relational database.
The programs did not change much, but the data structures changed radically. Program code was patched to provide for the new data structure.
The amount of people-time allocated to policyholder maintenance grew 15% per year over the last five years and is now costing as much per year as it did in 1980 to develop the original application.
No one ever considered reevaluating the subsystem for redevelopment, but they would like to now.
Upon inspection, the documentation was found to be up-to-date and includes flow charts and data flow diagrams.
There are no current diagrams of the data structure.
There are also no historical files of decisions or of changes.
According to Figure 18-2 (Conger, 2008, p. 750), the development team should follow a decision tree to determine the maintenance type to perform.
The statement indicates that the application is working but with some troubles, so there is no need for an entire rebuilding of the application.
The next step is to evaluate the maintenance cost which the statement indicates that it is super high.
The text recommends a restructuring of the part that does not work to fix them quickly, then a reengineering of the application as part of ongoing maintenance.
The first step is to restructure the application to fix the problems, and the statement indicates that the documentation are up-to-date, and the program did not change much.
From all information available, the team needs to restructure the data structure only, and build a bridge that connects the new data structure to the application interface. Doing so will allow the application to work with the new data structure in a short time that minimizes the organization’s cost.
Since the historical files are not available, the team should preform limited reengineering task around the data structure, to extract the current data structure in place and improve it. The reengineered data structure should be totally normalized and performant.
If the current program can not accommodate the new data structure, an intermediate module (bridge) should be built to connect the new data structure to the application interface.
Once the new data structure and the bridge have been built, they must be fully tested and integrated into the current application.
The new data structure and bridge should be batched and deployed to the production environment.
Once the production environment is updated and the program works well in the production environment, the long running reengineering task should be started.
The second part is an entire reengineering of the application. Since we have optimized the data structure, the application should be reengineered to take advantage of the new data structure without the bridge.
The bridge module was a temporary solution to fix the problem, and it should be removed as part of the reengineering task.
Every part of the program must be fully tested and integrated into the current application.
The documentation must be updated to reflect the new data structure and the new application.
All decisions must be documented and the historical files must be created.
Once the reengineering task is completed, the application should be batched and deployed to the production environment.