Building

When the Planning Phase milestones have been met, the next phase—Building—begins. The first step in building the deployment is creating and testing the solution.

On This Page

The Developing Phase The Developing Phase
The Stabilizing Phase The Stabilizing Phase

The Developing Phase

The Developing Phase is the period during which the team builds and unit-tests the solution. The Developing Phase culminates in the Scope Complete Milestone, indicating that the solution is ready to be tested (piloted) in production.

Key Tasks

Table 7 lists key developing tasks and deliverables and their owners.

Table 7. Developing Phase Key Tasks , Deliverables , and Owners

Key tasks

Deliverables

Owners

Starting the development cycle

Distribution server for the development work

Development

Creating and testing application mitigation packages and strategies

Mitigation strategies and mitigation packages

Development

Preparing the computing environment

A computing environment ready for development work

Development

Developing the solution scripts

A configured imaging and distribution server with updated script, Windows Vista, and applications; disk images

Development

Developing security configuration

Security configuration files and Windows Firewall configuration

Development

Developing core and supplemental application packages

Core applications packages, including the 2007 Office system, and supplemental applications packages

Development

Developing USMT configuration files and test cases

USMT configuration files and test cases

Development; Test

Developing deployment procedures

Deployment procedures

Release Management; User Experience

Developing operations procedures

Operations procedures

Release Management; User Experience

Creating test cases and scenarios

Test cases and scenarios

Test

Testing the solution

A solution ready for piloting

Test

Approving the key milestone: scope complete

All Developing Phase work complete

All roles

Team Focus

Table 8 outlines the primary activities of each team role during the Developing Phase.

Table 8. Developing Phase Role Clusters and Focus

Role Cluster

Focus

Product Management

  • Managing customer expectations

Program Management

  • Managing the functional specification

  • Project management

  • Updating plans

  • Application mitigation strategies and application packages

  • Security configuration

  • USMT configuration files

Development

  • Script creation

  • Infrastructure development

  • Documentation

  • Image creation

Test

  • Test lab, test scenarios, and test cases

  • Functional testing

  • Issues identification

  • Documentation review

User Experience

  • Training

  • Usability testing

Release Management

  • Deployment checklists, updated pilot plans

  • Site preparation checklists

  • Operations plans

IT Operations and the Security feature team are included in the assessments to ensure that an accurate view of their respective areas is addressed. The user community is included to ensure that the plans and designs being compiled are consistent with its needs.

Feature Team and Job Aid Documents

The following documents will be useful in the Developing Phase:

  • Functional specification (See “Creating the Functional Specification” earlier in this guide.)

  • Risk assessment (See “Creating the Risk Assessment Document” earlier in this guide.)

  • Application Compatibility Feature Team Guide

  • Computer Imaging System Feature Team Guide

  • Deployment Feature Team Guide

  • Desired Configuration Monitoring Feature Team Guide

  • Infrastructure Remediation Feature Team Guide

  • Operations Readiness Feature Team Guide

  • Security Feature Team Guide

  • Test Feature Team Guide

Starting the Development Cycle

The solution script includes files and programs used to create a generic installation architecture for Windows and the 2007 Office system and easily customize it to meet the organization’s needs. The script includes software teams can use to set up an imaging server and customize boot CDs that are used to begin the installation process on individual computers and tools teams can use to prepare the system for creating hard disk images for distribution throughout the organization. Teams must have licensed copies of Windows and the 2007 Office system and, depending on the scope of the project, sufficient licenses for any other software needed to carry out the project.

It is generally a good idea to divide the development work into several periodic builds that the team can thoroughly test as independent units before the entire scope of work is complete. This process helps the project remain on track by providing short-term checkpoints, at which the team can assess progress and make changes, if necessary. It also helps minimize the impact and cost of issues by bringing them to light sooner in the development process.

Using Interim Builds

Infrastructure development is the process of using regular, or interim, builds to convert functional specifications and plans into a complete, deployment-ready solution. Using interim builds, teams can find issues earlier than if they waited until the end of the Developing Phase to build the solution. In addition, the Test feature team becomes involved in the development process earlier, which shortens the development cycle and lowers the cost of the project.

The team should use interim builds as synchronization points where developers check in the scripts they believe are ready for testing. The developers submit portions of the solution to the Test lead, who assembles the build and tests it while the developers continue to work on additional script components.

The first interim builds should be fairly simple—for example, an unattended installation of Windows and the 2007 Office system on a single computer with the UI customized for the environment. Subsequent builds should add support for additional hardware and any additional functionality until the final interim build before the pilot, which should incorporate all the functionality dictated by the functional specification.

Figure 6 is a flowchart illustrating the unattended installation development process as an example of an interim build.

Figure 6. The unattended installation development process

Figure 6. The unattended installation development process

Creating Issue-Tracking Procedures

The team uses issue tracking to manage risk and help build an effective solution. An issue is anything in the solution that negatively affects its ability to perform as specified—in short, a bug. Issues can occur almost anywhere in the solution and can include problems such as defects in the solution scripts, missing or obsolete device drivers, and incompatibilities between script components.

The team cannot successfully move past the Developing Phase until every known issue is resolved. To resolve the issue, the team does not necessarily have to fix it. For example, the issue may be of sufficiently low priority that the team elects to defer action until a later version of the solution or not to act on it at all.

Testers document issues as they find them. Each tester should add issues to the issue-tracking mechanism, with an estimation of the severity of that issue and a description of the steps necessary to reproduce it. Estimate the severity by using a numeric scale, typically from 1 to 4, with 1 being the most severe and 4 being the least severe. As with the risk-management practices the teams have been using throughout the project, this approach enables the Development Role Cluster to prioritize issues and rank them according to impact so that the developers can address the most severe issues first.

The Development lead prioritizes the issue using a similar scale. Then the lead assigns it to the developer responsible for that feature for resolution. The worst possible issue is one with a severity of 1 and a priority of 1. This is an issue that crashes the solution and must be tracked down and resolved.

The information the tester documents during the issue-tracking process is invaluable to the training and support staff. It shows them the history of the solution, the problems encountered during development, and the resolution.

A well-implemented issue-tracking system does not have to be custom-built. At the low end, a spreadsheet program such as Excel can serve to track issues and rank them by severity and priority. With a little more work, teams can use a database application such as Microsoft Office Access to build a database with custom fields for easier and more accurate data entry. Or if time, resources, and the nature of the project permit, teams can tailor a dedicated issue-tracking program or build one from scratch. The issue-tracking database becomes a permanent part of the project and is a deliverable of the Developing Phase.

The Development and Test Role Clusters should meet regularly to review issues and plan strategies for resolving them. A well-designed issue-tracking system is of little use without a good review process.

Preparing the Computing Environment

Most feature teams need a lab environment. Although separate labs could be constructed for each feature team, most organizations create a single lab that shares facilities such as servers, networking, system backup, and data repositories (such as Visual SourceSafe), with separate workspaces (computers and network shares) for each feature team. This enables the teams to work separately when necessary and jointly when appropriate. In addition, the organization can minimize the number of computers and servers required.

Developing the Solution Scripts

If the project has been sufficiently envisioned and planned, developing the solution scripts does not have to be an especially difficult or lengthy process, but it does need to be well coordinated. Several basic functions relating to development occur at this stage. Among them are:

  • Application packaging.

  • Application remediation.

  • Data retention.

  • Creating computer images.

  • The deployment process.

Application Packaging

For the migration to be successful, users must have all the applications they need installed and ready to go. These applications must be packaged so that the scripted installation process can successfully install and configure each required application.

Using the information obtained during the Envisioning and Planning Phases when the application compatibility remediation tool was run, the developers have a list of applications that require packaging for automated installation and configuration. These are typically the items requiring the longest lead time. It is common for an organization of 5000 to10,000 computers to have 1000 applications or versions of applications that require packaging. Acquiring the software is also a time-consuming task. The earlier this task is started, the more efficient the process will be.

In addition, it is beneficial to identify an SME for each application. SMEs are usually power users from the organization who have deep knowledge of the application and how it should be configured and who can validate that the application is working correctly. SMEs aid the developers in determining how best to install and configure each application.

This is an excellent time in the project to review these applications, consolidate those that are redundant, and standardize the enterprise on fewer applications. For example, it is less expensive and easier to support one word-processing application or version of an application than it is to support two or three. It also facilitates easier sharing of documents across the enterprise if everyone is using the same application version.

The application packages created during this phase are further validated in the Stabilizing Phase and are used in the Deploying Phase of the project.

Note   Refer to the Application Management Feature Team Guide for information about how to package applications.

Application Remediation

Using the information obtained from the Envisioning and Planning Phases when the application compatibility remediation tool was run, developers have a list of applications installed in the enterprise. They must research and evaluate each application to ensure that it functions under the new operating system. In some cases, the analyzer tool provides information about the compatibility state of an application; in other cases, developers must either research the application through the vendor who wrote it or load and test it on Windows. For applications that will not function correctly under Windows, develop a plan for managing these applications.

Note   For information about how to use the analyzer tool to test and remediate incompatible applications, see the Application Compatibility Feature Team Guide.

Data Retention

During the Developing Phase, the developers review the lists of applications that are to be redeployed with an eye toward capturing user data files and application settings. They use the User State Migration Feature Team Guide to customize the configuration files that USMT uses to ensure that the proper data files as well as the application and user-preference settings are captured and restored during the Deploying Phase of the project.

Creating Computer Images

While some development teams are busy addressing applications and data retention, the Computer Imaging System feature team has the task of creating the computer images that will be used throughout the enterprise during the Deploying Phase. They will use the Computer Imaging System Feature Team Guide to build the imaging server, create startup CDs, and then create the deployable Windows images. They will customize the imaging process to reflect the business requirements that are defined in the functional specification.

These developers may also be engaged early in the project to assist with creating prototypes of images or computers. It is often beneficial to have a model computer present when discussing the components of the functional specification in the Planning Phase so that the team can evaluate the look and feel of a particular configuration.

Deployment Process

The developers working on the deployment process focus mainly on integration issues. They help define the preset options used in the deployment wizard, validate that the deployment process works with various images, and ensure that all the network shares, credentials, and other components are working properly.

They use the technical guidance on the imaging and deployment processes to guide their work. They also work closely with the Release Management Role Cluster.

Documenting the Development Process

When creating the development plan in the previous phase, the team should have specified the configuration documents that it would have to create during the Developing Phase. Typically, these would include documents describing the:

  • Configuration of the unattended installation architecture.

  • Deployment architecture.

  • Configuration of Windows.

  • Configuration of the 2007 Office system.

  • Data-reclamation process.

  • Application-packaging process.

  • Application-remediation process.

  • Specific hardware configurations to be deployed.

Teams must document their work as they continue through the Developing Phase. Teams are not only building the solution but also creating processes and procedures that others must follow when testing and deploying the solution. Documents to create can include:

  • A checklist that IT personnel can use to perform an unattended installation from start to finish.

  • Any site deployment checklists provided for in the development plan.

  • Procedures for creating hard disk images to aid in deployment.

  • Documents to help test the solution.

Developing Deployment Procedures

For a successful deployment, several kinds of documents are necessary. These include training and communications materials and site deployment and operations procedures.

Creating Site Deployment Procedures

Deployment procedures help carry out the deployment with greater efficiency. Creating a checklist of tasks for each site Deployment feature team to perform can help simplify and standardize the process of deploying the solution across sites. The pilot provides an opportunity to review and revise the deployment procedures.

Creating Communications Materials

Follow the communication plan, revising it as necessary to incorporate new developments in the project. The Product Management Role Cluster takes the lead in communicating with the customer. The User Experience Role Cluster takes the lead in communicating with users. The Release Management Role Cluster takes the lead in communicating with IT personnel. Rely on experienced people with good communications skills to drive this process.

Creating Training Materials

Before the team deploys the solution to the pilot group, it should develop the training materials provided for in the training plan and use the opportunity to pilot the training materials as well as the solution. Follow the training plan, revising it as necessary to incorporate new developments in the project.

Developing Operations Procedures

System administrators use operations procedures to support, maintain, and operate the solution. The Release Management Role Cluster takes the lead in developing these procedures, which should be in place by the time the team pilots the solution. Several of the plans in the project plan, including the deployment and training plans, can help develop operations procedures.

Deploying Windows and the 2007 Office system requires changes in the management of client computers and servers. The operations procedures should address ongoing desktop support in light of these changes.

Procedures to create can include:

  • Maintenance procedures, including the proper care of client, server, and enterprise components.

  • Disaster recovery after primary deployment, including contingency plans for reinstalling distribution servers and restoration from backups.

  • New site installation procedures, with instructions on installing a new distribution server or Windows-based computer from scratch.

  • Performance and fault-monitoring procedures, explaining what IT personnel should be aware of and pay close attention to when the technology is being deployed and afterward.

  • Support and troubleshooting procedures for keeping baselines available and safe from changes so that the operations team can return to a known state when necessary.

Testing the Solution

Testers should follow the test plan to identify issues for other members of the team to resolve. Use the issue-tracking procedures created during the Planning Phase to document issues.

Approving the Key Milestone: Scope Complete

The Developing Phase culminates in the Scope Complete Milestone. At this milestone, all features are complete and the solution is ready for external testing and stabilization. This milestone gives customers and users, operations and support personnel, and key project stakeholders an opportunity to evaluate the solution and identify any remaining issues that must be addressed before beginning the transition to stabilization and ultimately to release.

Developing Phase Checklist

Before proceeding to the next phase, the Stabilizing Phase, verify that the following have been completed:

  • Application mitigation packages and strategies created

  • Application packages created

  • Computer images created

  • Core application packages, including the 2007 Office system, created

  • Deployment procedures developed

  • Frozen functional specification approved

  • Operations procedures developed

  • Risk-management plan updated and reviewed

  • Security configuration files and Windows Firewall configuration

  • Source scripts and executables for all deliverables created

  • Test cases and scenarios created

  • Test specifications and plans developed

  • Test lab prepared

  • Unit-tested proof of concept completed

Moving to the Stabilizing Phase

After all the developing tasks are complete, the team must formally agree that the project has reached the Scope Complete Milestone and that the solution is ready for general testing. By approving the milestone, team members indicate that they are satisfied with the work performed in their areas of responsibility.

As before, project teams usually mark the completion of a milestone with a formal sign-off. Key stakeholders, typically representatives of each team role and any important customer representatives who are not on the project team, signal their approval of the milestone by signing or initialing a document stating that the milestone is complete. The sign-off document becomes a project deliverable and is archived for future reference.

The Stabilizing Phase

The Stabilizing Phase addresses the testing of a solution that is feature complete. This phase is typically when pilots are conducted, with an emphasis on real-world testing and with the goal of identifying, prioritizing, and fixing bugs.

Key Tasks

Table 9 lists key Stabilizing Phase tasks and deliverables and their owners.

Table 9. Stabilizing Phase Key Tasks , Deliverables , and Owners

Key tasks

Deliverables

Owners

Conducting the pilot

Test case results and bug reports

Test

Application-mitigation strategies tested, issues resolved, and results reported to management

Tested mitigation strategies

Test; Release Management; Development

Operational readiness review

Operational readiness acceptance

Release Management

Final release

Final images and process

Development

Approving the key milestone: Release Readiness Approved

All Stabilizing Phase work completed

All roles

Team Focus

Table 10 outlines the primary activities of each team role during the Stabilizing Phase.

Table 10. Stabilizing Phase Role Clusters and Focus

Role Cluster

Focus

Product Management

  • Communications plan execution

  • Deployment launch planning

Program Management

  • Project tracking

  • Bug management

Development

  • Bug resolution

  • Script optimization

  • Application mitigation strategies

Test

  • Unit, functional, and integration testing

User Experience

  • Training materials

Release Management

  • Pilot management and support

  • Deployment planning

  • Operations and support training

  • Application mitigation strategies

IT Operations and the Security feature team are included in the project discussions to ensure that an accurate view of their respective areas is addressed.

Feature Team Documents and Job Aids

The following documents, useful in the Stabilizing Phase, are included in this solution:

  • Test Plan (job aid)

  • Risk Assessment (job aid)

  • Deployment Plan (job aid)

  • Application Compatibility Feature Team Guide

  • Application Management Feature Team Guide

  • Computer Imaging Systems Feature Team Guide

  • Deployment Feature Team Guide

  • Desired Configuration Monitoring Feature Team Guide

  • Infrastructure Remediation Feature Team Guide

  • Operations Readiness Feature Team Guide

  • Security Feature Team Guide

  • Test Feature Team Guide

  • User State Migration Feature Team Guide

Testing the Solution

Testers should follow the test plan to identify issues for other members of the team to resolve. Use the issue-tracking procedures created during the Planning Phase to document issues.

Identifying Testing Tasks

A matrix of testing tasks can be an efficient tool for identifying testing tasks and assigning them to different testers. If the Test feature team developed a test matrix as part of the test plan, it should take this opportunity to revisit and expand the matrix. If the testers have not created a matrix, they should create one now.

Divide the testing tasks by functional area. For example, the Woodgrove project team divided its test matrix into tasks related to the following:

  • The deployment server

  • The imaging/build server

  • The boot CD-ROM

  • Windows baseline installation

  • Windows configuration

  • Windows logon

  • Windows functionality

  • The 2007 Office system

  • Computer hardware settings

  • Hard disk–based image installation and configuration

  • Windows DS–based image installation and configuration

  • Deployment process testing (such as backup, USMT, and application installation)

Conducting the Pilot

The solution is ready for the pilot deployment as soon as a full build has been completed and passed testing. Follow the pilot plan, revising it as necessary to incorporate new developments in the project. Use the communications and training materials developed to keep users informed as to the nature and progress of the pilot. A well-planned pilot of a sufficiently tested solution should present few surprises.

Although the team will not have deployed the solution to the full production environment at this point, it must have at least part of the support structure in place to deal with issues arising from the pilot, with support personnel standing by to assist users.

Collecting User Feedback

Tell users how long the feedback period will last and how to communicate their comments. Process the feedback according to the Pilot plan. If the teams have been using an issue-tracking database throughout development, they should continue its use during the feedback period to record issues that users uncovered.

When customer and user feedback indicates that the pilot is working, have the team review the work that has been performed during this phase, and then proceed to the Deploying Phase.

Interim Milestones

The Stabilizing Phase of the MSF Process Model contains interim milestones. Use the information and techniques in this guide to complete each milestone in the order provided. Following these milestones in order ensures the gradual development, testing, and stabilization of the solution. The two interim milestones in the Stabilizing Phase are:

  • Pilot Readiness Review Complete. To complete this milestone, the project team must expose the (now almost complete) solution to representatives of the various groups that will interact with the solution while it is still in the development environment. For example, the deployment group, the support group, and the proposed users of the solution are typical candidates.

  • Deployment Readiness Review Complete. To complete this milestone, the project team moves the now completed and frozen solution to a limited release in the production environment. This dress rehearsal for the project team helps it practice the full deployment of the solution.

Approving the Key Milestone: Release Readiness Approved

The Stabilizing Phase culminates in the Release Readiness Approved Milestone. This milestone occurs when the team has conducted a successful pilot, addressed all outstanding issues, released the solution, and made it available for full deployment. This milestone is the opportunity for customers and users, operations and support personnel, and key project stakeholders to evaluate the solution and identify any remaining issues they must address before deployment.

Stabilizing Phase Checklist

Before proceeding to the next phase, the Deploying Phase, the following items should have been addressed:

  • Final release of images and process

  • Project documents and release notes

  • Approved operational readiness review

  • Source scripts and executables for all deliverables

  • Computer images

  • Application packages

  • Tested application-mitigation strategies and packages

  • Test case results and bug reports

  • Deployment procedures

  • Operations procedures

Moving to the Deploying Phase

After all the Stabilizing Phase tasks are complete, the team must formally agree that the project has met the Release Readiness Approved Milestone and that the solution is ready for general release. By approving the milestone, team members indicate that they are satisfied with the work performed in their areas of responsibility.

As before, project teams usually mark the completion of a milestone with a formal sign-off. The sign-off document becomes a project deliverable and is archived for future reference.

Download

Get the Microsoft Solution Accelerator for Business Desktop Deployment 2007

Update Notifications

Sign up to learn about updates and new releases

Feedback

Send us your comments or suggestions