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.
Figure 4.11 Versioned releases within the MSF Development Process Model
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:
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.
In our opinion, by executing limited development tasks outside the Development phase, the team gains two major advantages:
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.
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:
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.