Planning Execution


To ensure a successful migration, a number of techniques should be used throughout the migration project. These include:

  • Milestones and checkpoints, to ensure that the project plan is followed and to reveal any risks as they arise.

  • Frequent delivery, to enable quality checks and to exercise the migrated software.

  • Metrics, to provide visibility on project progress.

At the end of the project, you should conduct a closedown review to ensure that any valuable lessons that have been learned are documented and to check off any completion actions, such as final sign-off of deliverables and archiving of documents and earlier software versions.

Milestones and Checkpoints

The migration process should be based on milestones and checkpoints or review points. Milestones are a definite, scheduled point in time when a material object must be delivered. Frequent checkpoints verify that the team is making progress toward the goal of delivering the completed software.

The shorter the project, the more often you should have a checkpoint or review to assess progress. For example, during a two-week project, there should be short, daily reviews at the very least. The sooner you correct a problem, the easier it is to fix and the more time you have to devote to delivering the full functionality on time. If this seems extreme, think about a year-long project, which would typically call for weekly status meetings. That would be fifty-two meetings over the course of the project. For a two-week project, daily meetings would amount to a total of only ten. In terms of percentage of work completed, the two-week project would progress much farther between checkpoints than would the year-long project.

Frequent Delivery

Each stage of the project should have one or more concrete deliverables, each of which is appropriate for that stage of the migration. The milestone for each phase is the completion of the deliverable item. For example:

  • Assessment and analysis . The deliverable of this phase is a business case that is supported by a comprehensive set of analysis results.

  • Planning . The deliverable of this phase is a functional specification, migration plan, and risk catalog.

  • Development environment . The deliverable of this phase is a working environment, with code imported and ready to migrate.

  • Development . The deliverable of this phase is the completed code, which compiles to result in a working, testable application.

  • Testing . The deliverable of this phase is an application that conforms to its specification with all appropriate bugs addressed.

  • Deployment . The deliverable of this phase is a statement of user satisfaction.

Larger migration projects have multiple deliveries from the development phase. Product release is the final project milestone that culminates the testing and deployment phase. This means that the project is complete and that the vision has been achieved. The next phase, closing down the migration project, is actually the beginning of the next loop in the life cycle of projects.

Two additional techniques used by Microsoft are doing daily builds and using the software being developed. Doing daily builds of the entire code base ensures that no problems have been introduced that prevent the whole system from begin created. Eating your own dog food means that the developers exercise the new software every day. Clearly these techniques may be difficult to apply early in the migration process, which relies on the migration of the build environment. However, the number of builds and the use of the resulting application should increase throughout the migration.

Project Metrics

Having the team define and track metrics is another procedural item that can help with tracking progress. It is common to measure items such as function points, requirements achieved, bug counts, or number of lines of code written or converted. The development and testing teams should pick a set of metrics that are useful in tracking migration progress. To be useful to the whole team, these metrics should be made available on a regular basis. Team members can decide whether this is done through e-mail messages, a team intranet Web site, a share on a server, or by other means. Whatever the choice, it should fit into their regular routines so that the process of checking the figures is a natural extension of their work habits.

Do users expect a summary document, a detailed report of the test cases, or a recapitulation of the testing, test results, and migration strategy? Further, do they expect any progress reports as you carry out your testing? Knowing what you need to produce from the testing helps you to focus and structure your approach to the testing itself.

Closing Down the Migration Project

At the completion of the migration project, the project team should analyze the results and produce documentation that can be used in subsequent migrations. The documentation may include a paper that describes what was done and what happened . The paper should include details of which things worked, but more importantly, it should include information about what did not work as expected and what was done to fix the problems. For example, the report should include information about significant porting problems such as:

  • Availability of required tools (compilers, debuggers , analysis).

  • Lack of third-party libraries (math, X Windows).

  • Infrastructure issues, including file access security.

  • Makefile issues.

  • Script usability.

  • API migration issues.

In addition to creating documentation, program management may want to create presentations for the customer or upper management.

As the final action to conclude the project, the team should decide how to proceed in the future. The next step is often the beginning of another project with the team envisioning the migration of other, larger applications. If the migration project runs into significant issues, the team should address these through use of prototyping before beginning a more complex migration. With the prototype project completed, the organization can begin moving significant, line-of-business applications to the Windows platform. By following the framework for software development, the organization gains valuable experience in both the tools required and the process for migrating from UNIX to Windows.




UNIX Application Migration Guide
Unix Application Migration Guide (Patterns & Practices)
ISBN: 0735618380
EAN: 2147483647
Year: 2003
Pages: 134

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net