Process 2: Develop the Solution

In this process, Development develops the solution, User Experience writes the documentation, and Test reviews the builds.

Figure 4. Develop the solution

Activities: Develop the Solution

The primary activity that occurs during this process is the development of the deliverables, for which Development is primarily responsible.

Additionally, User Experience develops user and IT documentation during this process. In many cases, documentation is the key part of the solution. This is particularly true when building infrastructure solutions.

Test reviews each interim build of the solution, including code and documentation, and logs issues in the issue-tracking database. The development process is not linear but is an iterative one that relies on creating interim builds. By creating and testing interim builds, the team can find and fix solutions earlier in the development process—before those issues become major problems.

Because the development process focuses on developing the solution, the project needs interim milestones that can help the team measure build progress. The development of the solution’s components is done in parallel and in segments, so the team needs a way to measure progress as a whole. Internal builds accomplish this by forcing the team to synchronize components at a solution level. The number and frequency of the builds depends on the size and duration of the project. In most cases, it makes sense to set interim milestones for completion of the user interface design and database schema because there are many dependencies on these—for instance, User Experience needing screen shots for the documentation.

The following table lists the activities involved in this process. These include:

• Developing the solution deliverables.
• Developing the solution documentation.
• Testing the solution.

Table 5. Activities and Considerations for Developing the Solution

Activities

Considerations

Develop the solution deliverables

Key questions:

• Is this project a continuation of a previous version?
• Do the developers require training for the tools they’ll be using?
• Is a change control system in place for version tracking?
• Does the project team have a clear approach for handling tradeoffs (trading features for schedule, performance for features, and so on)?
• Does Development understand the business and technology drivers?
• Does Development have clear design goals, such as designing for security, designing for interoperability, and so on?
• What guidelines and standards, such as naming standards, must Development follow when developing the solution code?
• Does the project team have a version control system?
• Does the project team have an automated, daily build process?
• What third-party components and development tools will the team use?

Inputs:

• Functional specification
• Master project plan, including the development plan
• Development and testing lab

Outputs:

• Interim solution builds
• Solution deliverables, including:
  • Release notes.
  • Code and executable files.
  • Configuration documentation.

Best practices:

• The axiom measure once, cut twice; measure twice, cut once applies to development. Thorough planning and design leads to simpler development.

Develop the solution documentation

Key questions:

• Is this project a continuation of a previous version?
• Is a content management system available?
• Will User Experience repurpose existing documents or start from scratch?
• Does User Experience fully understand the technology being developed?
• Does User Experience understand the business and technology drivers?
• Does User Experience have clear design goals for the documentation, such as readability, accessibility, or portability?
• What guidelines and standards, such as editorial or style guidelines, must User Experience follow when developing the solution documentation?

Inputs:

• Functional specification
• Master project plan
• Interim solution builds

Outputs:

• Interim documentation builds
• User documentation
• Operations documentation

Best practices:

• Outline documentation and gain stakeholder approval before writing.
• Use collaborative software, such as Microsoft® Groove®, to ensure active participation and reviews of the documentation.
• Schedule regular meetings with Development and Test for demonstrations and reviews.

Test the solution

Key questions:

• Is the test lab prepared?
• Have the test plan, test scenarios, and test cases been refined?
• Has the test team thoroughly captured the vision/scope document and functional specification in the test scenarios and test cases?
• Is a daily build-process running that gives Test fresh code each day?
• Is the issue-tracking database dynamic enough to allow for agile development? For example, is a notification system available that can alert the project team when new bugs are added to the issue-tracking database or when their status changes?
• Is the project team carrying forward bugs from a previous version?

Inputs:

• Functional specification
• Master project plan, including the test plan
• Development and testing lab
• Interim solution builds
• Interim documentation
• Test scenarios and test cases
• Issue-tracking policies and procedures

Outputs:

• Issue-tracking database updated

Best practices:

• Use virtualization to minimize the physical hardware required to test.
• If a formal issue-tracking system isn’t available, create an issue-tracking system by using a product such as Microsoft SharePoint® Team Services.
• Create a lab schedule to avoid conflicts.

This accelerator is part of a larger series of tools and guidance from Solution Accelerators.

Download Get the Microsoft Operations Framework 4.0

Solution Accelerators Notifications Sign up to learn about updates and new releases

Feedback Send us your comments or suggestions