Process Model

The MSF process model is a product life cycle model adapted specifically for success in a client-server environment. It consists of four high-level milestones, each of which will be owned by one or more of the team project roles discussed above. To distinguish it from a more traditional "waterfall" process model, the MSF process model can be represented with a spiral diagram as shown in Figure 5.

Figure 5: The MSF Process Model

Here's a brief description of each of the high-level milestones.

• Vision/Scope Approved This milestone is owned by product management. The vision statement provides an opportunity for customers and team to agree upon a high-level vision of the application: the business requirements for the application, the problems it will solve and major constraints that it must satisfy.
• Functional Specification Approved Program management owns the functional specification. For custom applications, the functional specification should in principle provide enough detail to commit to a fixed-price estimate and a delivery schedule. Since the next major process phase is construction, the functional specification clearly needs to contain a sufficient blueprint for the development team to begin coding. In custom database applications, this should include all supporting system architecture documents (entity/relationship, process flow, screen specifications, pseudo-code, and so on).
• Code Complete The construction phase, concluded with the code complete milestone, is jointly owned by the development and user education project roles. At this milestone, product features and development have been frozen and support plans and documentation are in place.
• Release Testing and quality assurance should have been taking place before the code complete milestone is reached, but after that milestone the project focus is almost solely on testing and QA. The release milestone is jointly owned by the test/QA and logistics project roles.

In Figure 6 we show a more traditional life cycle diagram which suggests the Gantt view often associated with project methodologies. This figure makes clear the responsibility of the different project roles for the four major milestones, and also stresses that each of the six roles has important work to do in most of the project's phases.

Figure 6: A modified Gantt view of the MSF Process Model

There are several critical assumptions underlying the MSF process model, along with some caveats to be aware of. Here are some of particular importance to Visual Basic development projects:

• Your project infrastructure needs to be in place before things start: don't expect to figure out how to do version control or testing or naming conventions during the construction phase. Since you've already (supposedly) committed to a fixed bid, this is a great way to blow the budget.
• Notice how overlapping the team's roles are. Test/QA needs to be involved up-front as we've discussed, since at least outlining a test plan is critical input in the functional specification. Also notice how development is involved even in putting together the vision/scope document. In Visual Basic, development's contributions of early prototypes are critical in gathering customer input in design and completely specifying that design.

Tip: Be realistic about fixed bids. To us, the functional specification is usually the most critical deadline. With what we've discussed about testing alone, it's often impossible to commit to a fixed-bid estimate, unless you accept that you'll be doing post-release debugging gratis. So be realistic, and build yourself outs:

Avoid fixed bids if possible, but prepare a functional specification as if for a fixed bid.

If you have to work on a fixed bid basis, limit post-release debugging/technical support to a fixed time period and build that into your overall project costs.