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 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 |
|
Program Management |
|
Development |
|
Test |
|
User Experience |
|
Release Management |
|
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
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 |
|
Program Management |
|
Development |
|
Test |
|
User Experience |
|
Release Management |
|
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