A managerial perspective
5.5 Developing a reengineering plan
After determining that reengineering of existing legacy applications is an advantageous strategy, more detailed planning must be carried out. Virtually every organization employs a project planning process in various degrees of formality. This guide by no means claims to be a substitute or alternative for good local practice. A plan answers the questions why, what, how, when, where and how, how much and what if. The following sections present a number of memory joggers for the use of the reengineering planner to check the completeness of the plan, and as reminders of important kernel decisions that will a ect the outcome of the project.
5.5.1 Why
The plan should summarize the purposes and intent of the project, and how success will be deter-mined. The following questions should be answered by the plan:
What are the main reasons for reengineering?
What are the Critical Success Factors of the project?
What goals does the project hope to achieve?
How will the results of the project be measured?
5.5.2 What
The plan should summarize what tasks the project will accomplish. It should include descriptions of the source artifacts that will be used in the project, the deliverable outputs, and any signi cant in uences that will impact the project.
What fundamentally does the legacy product do?
What functional changes are expected?
What obsolete functions can be deleted?
CHAPTER 5. A MANAGERIALPERSPECTIVE 46
What hardware, software, and communications platforms will be targeted for the reengineer-ing system?
What software, hardware, or enterprise information architectural criteria will the project conform to?
What standards apply to the product, and how will conformance be assured?
What signi cant compatibility requirements apply to the project? Are there any internation-alization requirements?
What assumptions are being made that might a ect the project if they falter?
What signi cant constraints apply to the project?
What legacy artifacts will be used in the project?
What deliverable products are expected?
What o -the-shelf packaged components will the product comprise?
5.5.3 How
The plan should describe what methods, tools, and technologies will be used in the execution of the reengineering project. Any technology that is new or unfamiliar to the project sta should receive special mention.
What process model will the project follow?
What is the task decomposition (work breakdown schedule) of the project?
How will the quality of the deliverables be evaluated?
What equipment facilities will the project use for development, testing, and pilot deployment?
What software tools and technologies will the project use? Are any of them novel to the reengineering sta ?
What design methods will be used? Does the tool suite support the methodologies?
Has an inventory of legacy artifacts been completed? Are they under formal con guration management control?
CHAPTER 5. A MANAGERIALPERSPECTIVE 47
How will the legacy artifacts be conveyed to the reengineering sta ? How will the reengineered products be returned?
How will the reengineered system be tested and veri ed?
How will problem reports on the system be collected, processed, and tabulated? Will it be the same procedure used to support the legacy system, or a new or substantially modi ed one?
5.5.4 When
The plan should describe the sequence of events that the project will perform. Planning as many parallel activities as possible will reduce the calendar time of the project. Remember, however, that concurrent tasks will increase the management responsibility, and the importance of e ective inter-project communication.
When will the project start?
What is the overall schedule of the project?
When is it expected to be completed?
When, and what are the major milestones to be met?
When will necessary equipment be installed, and assigned sta be available?
What is the schedule for operational deployment?
Has the schedule been coordinated with the user community? When will any user community preparation take place?
5.5.5 Where and who
The plan should describe the sta that will participate on the project, and the geographic sites where the development and installation will take place. Particular attention should be paid to assessing the tasks needed for the project, the corresponding skills possessed by the sta , and how de ciencies will be made up.
Who will sta the reengineering project?
CHAPTER 5. A MANAGERIALPERSPECTIVE 48
Do the sta have experience in the legacy source languages, the target languages, and the application domain?
Do they have the necessary skills need to carry out the plan?
What training, practice, or other preparation will they need?
Will the current system maintainers be available to the reengineering sta ? How much of their time will be allocated to reengineering?
Will subcontractors or vendors participate in the project?
Where will the development take place?
Are there security requirements which will apply to the sta , contractors, or site(s)?
Who will maintain the system after reengineering? Do they know how their future work will be a ected by the reengineering? How are they being prepared for the change?
Who will represent the needs and interests of the user community?
Who will prepare the user community for the new system?
Where will the new system be piloted?
Where are all of the operational deployment sites?
Who will provide user support for the pilot and operational deployment sites?
5.5.6 How much
The plan should describe the quantitative aspects of the project, including how much legacy material there is, how much material is expected to be developed, and how the project will be measured.
Metrics should be carefully chosen to be non-threatening, and collection should be as non-intrusive as possible. Management should select a few, key metrics to track, rather than a broad set of metrics that may not add much value in understanding the status of the project.
How much legacy code is there? Is any of it missing?
What languages is it written in?
What measurements have been performed on the legacy artifacts, and what were the ndings?
What is the estimated size of the deliverable documents, code, or other artifacts?
CHAPTER 5. A MANAGERIALPERSPECTIVE 49
How much of the original system requirements, architecture, and design documentation is available?
How many personnel will be assigned to the project?
How much hardware and software equipment will be available to the project, or how much budget is there to acquire facilities?
What process and product metrics will be collected? How will they be interpreted and used?
5.5.7 What if
The plan should consider what risks confront the project, how those risks might confound project success, and the contingency actions available to cope with risks as they arise. The extent of the risk analysis will depend on the size and importance of the project, but every plan should devote some attention to the impact of deleterious events.
Has a risk assessment been conducted for the project?
Is the operational system currently under active maintenance? If so, will the reengineering project have to track the changes being made to the legacy system?
Has an organizational readiness assessment been done? It there resistance within the organi-zation to the reengineering project? How is the resistance being addressed?
Are there any critical upcoming events that will impact the deployment of the new system?