Traditional approaches to software development, such as the Waterfall and Spiral Models, often cannot meet the needs of today's enterprise application development environments.
With the Waterfall Model, a project progresses through sequential steps, from the initial concept through system testing. This model identifies milestones along the course of the project and uses them as transition and assessment points. This approach works well for a project in which requirements can easily be specified at the beginning, but may not work well for a complex project where requirements can change during the project's life cycle. Additionally, practitioners of this model rely heavily on volumes of documentation and a single review process for each stage. These two Waterfall practices usually lead to overextended "analysis paralysis" and adversarial relationships between developers, customers, and users.
Using the Spiral Model, the application evolves over a number of iterations. Early passes through the Spiral life cycle provide increasingly tight definitions of the product, with middle and later iterations adding features and functionality to the application. The Spiral Model seeks to confront project risks early in a software project and address them in early product releases. Due to its iterative nature, the Spiral Model supports creative adjustments along the way, thus evolving and hopefully improving the quality of product. The highly iterative Spiral process requires significant amounts of process and documentation automation to become efficient. In practice, customers and users may develop a general sense of instability because the product can change too rapidly for them to grasp. Finally, many Spiral projects lack a known ending point, so they continue to iterate indefinitely with no financial or business end within site.
As shown in Figure 4.5, the MSF Development Process Model combines the strengths of these two models, providing the benefits of milestone-based planning from the Waterfall Model and the benefits of the iterative creative process from the Spiral Model.
Figure 4.5 MSF Development Process Model
The MSF Development Process Model has three primary traits:
Although Figure 4.5 shows the four phases as quarters, the phases do not necessarily require equal amounts of time to complete. Different business and technological environments will require different time and resource ratios for the various phases.
The MSF Development Process Model consists of four interrelated phases. Each of these phases represent deliverables for which a baseline should be established before the development process can move to the next phase of the project. The four phases and their primary tasks are:
The MSF Development Process Model is based on milestones that are points for review and synchronization, rather than points for freezing the application or its specifications. They enable the team to assess the project's progress and make midcourse corrections, such as adjusting the scope of the project to reflect changing customer requirements, or reacting to risks that may materialize during the course of the project.
The MSF Development Process Model uses two types of milestones: major milestones and interim milestones. Each milestone, whether major or interim, is marked by one or more deliverables. Deliverables are physical evidence that the team has reached a milestone.
Each phase of the development process culminates in an externally visible major milestone. Externally visible means that the milestone and its deliverables are visible to entities outside the project team, such as the customer or operations personnel.
A major milestone is a point in time when all team members synchronize their deliverables. Additionally, those external to the project team such as the customer and users; operations, support, and help desk personnel; the distribution channel (commercial software); and other key project stakeholders, should be updated on the project status.
A significant role of major milestones is to allow for a stage-by-stage assessment of the project's viability. The project team and the customer, having reviewed the deliverables for the current phase, jointly make the decision whether or not to move into the next phase. Thus, major milestones serve to move the project from one phase to another.
Within each phase of the MSF Development Process Model are various interim milestones, which, like major milestones, are review and synchronization points, rather than freeze points. Unlike major milestones, however, interim milestones are internally visible—that is, visible only to members of the project team.
Interim milestones indicate early progress and break large work assignments into smaller pieces that are easier to address.
The MSF Development Process Model is a versioned process in the sense that it is designed to be repeated during the life cycle of a given product. Each succeeding completion of the MSF Development Process Model allows for the addition of features and functionality in order to satisfy changing business requirements.