Milestone-Based Process Model

   

Overcoming these drawbacks requires a more flexible, iterative, process-oriented development model. The milestone-based process model presented here is derived from the product life cycle model proven so successful within Microsoft Corporation. It encourages thinking about work in terms of processes rather than tasks. Milestones mark the self-regulation points of these processes.

The four characteristics of the milestone-driven model are:

• Milestone-based approach   The application development process is driven by external and internal milestones, which are checkpoints to guide the development process.
• Clear ownership and accountability   The process model connects responsibility for each milestone to the project team roles.
• Risk-driven scheduling   High risk components of a project are completed as early as possible.
• Versioned releases   The concept of versioned releases is an important one throughout the systems development life cycle because it impacts how expectations are set and how the entire project is planned and managed.

Each of these characteristics is discussed in the following sections.

Milestone-Based Approach

This process model consists of four high-level milestones as represented in the following diagram.

Process milestones

The milestones are depicted as points on a spiral — rather than a straight line — to emphasize that the process is cyclical and iterative rather than linear. Milestones are not freeze points. Rather, they are "baseline" points at which the deliverables described by the milestone are placed under change control. This facilitates flexibility and successive refinement.

Briefly, the four major milestones are described in the following list.

1. Vision/Scope Approved milestone

   Once a new application gains interest and approval, a project team is assembled to define the product. A vision statement establishes scope and provides direction. The Vision/Scope Approved milestone is an opportunity for both end users and the development team to agree upon the project scope and vision.

2. Functional Specification Approved milestone

   The next visible milestone is availability of a functional specification baseline. This specification provides enough detail about the application so that the project team can begin identifying resource requirements and determining commitments. At this milestone, users and team members agree on what is to be delivered and establish priorities and expectations. This is an opportunity to reassess risk and to revalidate earlier estimates for schedules and resources.

3. Code Complete milestone

   An approved functional specification provides the baseline for focused development to begin. The development team sets a number of interim delivery milestones, but the critical milestone is, of course, Code Complete. The Code Complete milestone is an opportunity for users and team members to make a final assessment of the release and to verify that rollout and support plans and procedures are in place. At this milestone all new development ceases, and any deferred functionality is noted for the next release.

4. Release of Product milestone

   After the code has baselined, beta programs, testing, and quality assurance activities are performed concurrently with further code refinement, driving the system to the Release milestone. The Release milestone is the point when the application (or "product") is formally turned over from the project team to the operations and support groups.

These four milestones are major progress points that embody all major development concepts. They are review milestones. Again, deliverables for the milestones are not frozen; instead, they are placed under change control.

Note   Throughout this chapter, the application under development is often referred to as a "product." While the strategies defined here certainly apply to developing commercial shrink-wrapped software, they are by no means limited to it. Rather, developing a mindset in which the application is a "product" has significant advantages, including rapid application development, willingness to postpone new or risky features for future releases, and adherence to fixed milestones and ship dates.