Overview of the Developing Phase

The Developing Phase is the third of the four phases of the MSF Development Process Model. The Developing Phase follows the Planning Phase, which is completed with the Project Plan Approved Milestone. To this point, the team has focused on product vision, product architecture, and project planning. During the Developing Phase, the team's focus changes to project execution.

click to view at full size

Figure 12.1 The Developing Phase

The team may ask, "How can we successfully implement our development process to ship the right product on time?" The answer to this question lies in a common understanding of the product vision. To further enhance the development process, the team should weigh this understanding of the vision with realistic limits for developing a functional software product. Developers should then implement the product defined by the project team.

As noted in Figure 12.1, the Development implementation leads to application coding being completed and initially released to the project team, resulting in the Scope Complete Milestone. This milestone of the Developing Phase has the following characteristics:

  • All product features are implemented, even if not fully optimized.
  • The product has passed basic testing and the current list of bugs has been addressed, although not necessarily fixed.
  • Team members and key stakeholders agree that the included features meet the product vision and design, and have been successfully implemented.
  • User performance materials are baselined and ready for testing and stabilization.

The Developing Phase contains many small similiarities to the other phases of the MSF Process Model. For example, results of the Planning Phase efforts would produce the following revised deliverables:

  • Functional Specification
  • Master Project Plan
  • Master Project Schedule
  • Master Risk Assessment Document

Where these deliverables are the output for the Project Plan Approved Milestone, they become the input and tools for the Developing Phase. The Planning deliverables are used as a forecast to quantify the implementation of the development process. These Planning deliverables should not be viewed as completely static; they are baselined and should be used as a guide in the Developing Phase. The deliverables for completing the Developing Phase will include revised versions of the Planning Phase deliverables, as well as the following:

  • Source code and executables
  • User performance materials
  • Testing elements

In this chapter, we'll discuss how to incorporate Project Plan Approved Milestone deliverables into the Developing Phase so that a team can begin to create a software product and reach the Scope Complete Milestone. Specific interim milestones can help continue the team's progress through the Developing Phase.

Often called "getting the real work done" on a development project, the true focus of the Developing Phase is building the product solution.

Planning Feeds the Developing Phase Deliverable

Architecting the product properly during the Planning Phase provides the context to implement the product during the Developing Phase. In the Software Project Survival Guide (Microsoft Press, 1998), Steve McConnell describes the transition between the two phases using the terms upstream and downstream. Application architecture work through the Planning Phase moves upstream, leading to the Developing Phase. Product work implementing the design moves downstream beginning at the Developing Phase and ending at the product release point. If a team's early upstream work is sound, the team members know exactly what needs to be implemented. If the upstream architecture is unsound, pieces derived from this architecture will significantly impede the project.

The Master Project Schedule describes the expected implementation schedule for the Developing Phase. The Functional Specification provides the Conceptual, Logical, and Physical application designs, the foundation for physical code implementation. The project's risk assessment and management must continue to be proactively managed as the risk's probability and impact fluctuate throughout the project. Also during the Developing Phase, the team will implement the Development Plan incrementally, using interim milestones as mentioned.

For example, in moving from Envisioning to Planning and into Development, one logical architectural requirement may map to a dozen physical design templates, which may, in turn, be able to map to hundreds of lines of actual code. In moving from design to coding, the team certainly can't implement all features, services, and object code at once—the code must be implemented in manageable portions. As each code segment is integrated, it will be combined with the others to form the complete application.

Each new compilation of the application can be made available as an interim product release during the Developing Phase. At some point during the product development, these interim releases are made externally available in the form of alpha and beta product releases.

Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit
Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit
Year: 1999
Pages: 182

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