Using Versioned Processes

Throughout this book, we emphasize the concept of using versioned releases. As Figure 4.11 illustrates, using versioned releases means repeatedly going through the MSF Development Process Model, delivering increasingly feature-rich versions of the same product. In this part of the chapter, we'll expand on the concept of versioning by first giving some additional guidelines for creating versioned releases. Then we'll discuss how our experience takes the concept even further, by suggesting that the project team can create multiple iterations of the MSF Development Process Model within each versioned release.

click to view at full size

Figure 4.11 Versioned releases within the MSF Development Process Model

Guidelines for Versioned Releases

As soon as the project team begins work on the first version of a new software application, it should already be planning the creation of the second version. This iterative process is helpful throughout all four phases of the MSF Development Process Model. For one thing, the team can assign feature requests to various versions, which in turn enables it to deliver the core functionality in the first version, and subsequent features in later versions. In addition, the realization that decisions made for the first version will have to be revisited for subsequent versions motivates everyone to make well-considered decisions the first time!

There are six overall guidelines for creating versioned releases:

  • Adopt a product mindset Constantly keep in mind the ultimate goal of building the version that delivers the complete feature set. Having a product mindset helps the team think beyond the current version by focusing on execution and on what is being delivered at the end of the project.
  • Create a multi-version release plan Be sure the product release plan takes the various versions into account.
  • Cycle rapidly Remember that the customer and users will be more willing to accept that certain features won't appear until later versions if they are confident that the team can deliver those versions.
  • Analyze each feature request for impact, feasibility, and priority Think beyond the current version to increase the team's capacity to make sound decisions about what to build now and what to defer until a later version.
  • Deliver core functionality first so that there is a solid first release to build on Address the primary business issues the product is supposed to address. If the team demonstrates the ability to plan and execute the delivery of the software based on the business issues, customer and user confidence in the team will increase.
  • Stop building new versions when they no longer address business needs Know when to stop adding versioned releases. If a new release isn't supported by a strong business need, another version isn't necessary.

Phases and Living Documents

Earlier we described living documents as documents that change throughout a project. The flexibility of the development process is the reason living documents are necessary.

For example, one of the deliverables of the Envisioning Phase is the Vision Document. A traditional Waterfall-like approach to project management insists that the Vision Document be complete in all respects before the Planning Phase can begin. By contrast, the MSF Development Process Model assumes not only that the document is not complete before the Planning Phase, but that although the document has a baseline, it will not be complete until the project is complete. The Vision Document delivered during the Envisioning Phase is the baseline version of the document, but the document won't be finished until the end of the project. The document is refined more and more with each phase of the MSF Development Process Model.

Development Tasks During Other Phases

In our opinion, by executing limited development tasks outside the Development phase, the team gains two major advantages:

  • Forward movement Immature development teams typically do very little analysis and planning. The drive is to simply "get to coding." When the team members realize the errors of their ways—often through a painful failure—the members move to the opposite extreme and determine to write code only when every detail of the plan is complete. If the team can keep moving through the plan/build cycle using development tasks where appropriate, it won't get stuck in either planning or building mode. Additionally, executing portions of the application code gives the entire team a sense of accomplishment and progress. No one task seems to go on forever; the team is meeting deadlines, accomplishing goals, and identifying and managing problems. It is moving forward through the process, with a growing sense that the project will be successful. This sense of success feeds back into the team system, generating exponential improvement.
  • Early warning system One of the major objections to the traditional Waterfall Model is that mistakes and errors are not identified until the end of the process. However, having development tasks early in a project gives the team an early warning system for identifying errors much sooner in the process, so that they can be fixed when the cost is low.

For example, suppose the team is planning a distributed application: the bandwidth requirements have been calculated on paper, and the network demands appear acceptable. As part of the Planning Phase, the team decides to build a proof-of-concept working version of the application to test the architecture. (Note that the Developing Phase hasn't begun yet; a task of development occurs within the Planning Phase.) The proof-of-concept system reveals that the application seems to take much more bandwidth than the team had calculated. In fact, if the application is built and deployed as designed, it will saturate the organization's current network. The team rethinks its approach and finds a better design. A second working version is built, and this one is much more frugal with network resources. There is no need to ask ourselves, "Where would we rather discover such a problem: during the Planning Phase, at the end of the Developing Phase, or even when the application is actually deployed?" Obviously, an early discovery is better than a late one. The only way to gain this early warning system is to execute limited development tasks as needed within each phase of the project.

Development Task Goals

As we noted earlier, the team can avoid the pitfalls of the Spiral Model by determining the development tasks for each phase early in the project life cycle. Each phase normally has a primary purpose, one for each of the Envisioning, Planning, Developing, and Stabilizing Phases.

All the goals set for a development task should flow out of the goals for the parent phase. For example, the goals of the Envisioning Phase are agreement on business needs, a common vision, a set of design goals, and so on. The goals of any development tasks within the Envisioning Phase should relate to that phase's goals. Any goal that doesn't should be delayed or dropped.

Aligning development tasks with phase goals keeps the team from working on a task before its time. A common failing is to begin doing extensive development work before the architecture is established. Establishing the architecture is done as part of the Envisioning and Planning Phases; the extensive development work is part of the Developing Phase. Doing such work any sooner may turn out to be wasted effort.

In many projects, the goals of the development tasks follow this pattern:

  • Prototype During the Envisioning Phase, a prototype can be a useful means of communicating and refining the vision. A prototype is a non-functional, visual version of the product. Often it is nothing more than a series of linked screens. If the application is to be Web-based, the prototype may be a series of Web pages. If the application is desktop-based, a simple mock-up can be constructed in Visual Basic or Access. The point is that the prototype is simply a way to get agreement between the project team and the customer on the overall vision of the product and the user interface.
  • Proof-of-concept system In contrast to the non-functional prototype, the proof-of-concept system is a functional application used to ensure that the design is achievable. While the prototype is primarily concerned with concept and user interface, the proof-of-concept system is primarily concerned with design and technology. Can a stable, useable application be built with the envisioned design? Typically, a proof-of-concept version of the product is built during the Planning Phase.
  • Alpha, beta, and subsequent interim releases During the Developing Phase, the development team often creates alpha and beta releases. These interim releases demonstrate the gradual melding of the prototype's user interfaces and the proof-of-concept's technologies. A large project may have many such releases during the Developing Phase. We recommend the release of at least an alpha and a beta version for all but the smallest projects. The alpha release says, "Here is our first cut at putting interface and technology together. What are the major issues?" The beta release says, "We think we've dealt with all the major issues and most of the minor ones. What have we missed?" This phase culminates with the creation of the golden release candidate.
  • Golden release During the Stabilizing Phase, the golden code is pilot-tested by the user community. Additionally, bug fix releases are tested and deployed as performance or environment problems are determined. The final golden release at the end of the Stabilizing Phase signals the completion of the project and transfers all product deliverables to the customer.

Some development teams resist creating prototypes or proof-of-concept systems because they see them as a waste of time. In reality, the opposite is true. Even for smaller projects, a prototype and a proof-of-concept system can ultimately save the team much wasted time and effort by clarifying the customer's needs and by testing the design. It's better to spend a little time on an earlier version that gets discarded than to spend a lot of time on a later version that gets discarded.

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 © 2008-2017.
If you may any questions please contact us: