Each of the four phases of the MSF Development Process Model concludes with a major milestone. In this overview, we examine each of the phases briefly with the goal of establishing the basic tasks of each phase and their relation to each other. In later chapters, we'll explore the phases in more depth and suggest interim milestones for each one.
The purpose of the Envisioning Phase is to build a shared vision of the project among all the key stakeholders. This vision should include:
Defining the variables more exactly and establishing their triangulated balance is an iterative process. As analyzing, prototyping, and planning activities proceed, the team may revise the scope because of:
By creating a broad but intuitive view of the project's goals and constraints, the Envisioning Phase begins to define the scope of the project, and sets the stage for the more formal and detailed planning effort that will come later, in the Planning Phase.
The Envisioning Phase culminates in the Vision Approved Milestone. This first milestone represents the point at which the project team and the customer agree on the overall direction for the project, including what features and functionality the product will and will not include.
Reaching this milestone meets one of the most fundamental requirements for project success—unifying the project team. The team must have a clear vision of what it wants to accomplish for the customer, and must be able to state that vision in terms that will motivate both the team members and the customer.
The deliverables of the Vision Approved Milestone are:
We also recommend that a prototype system be included with the deliverables for this milestone.
As explained earlier, the completion of major milestones results in a synchronization between the customer and the project team, and provides an opportunity for determining whether or not to proceed. Smaller function teams, as described in Chapter 3, must also synchronize with the main project team at major milestones. The Vision Approved Milestone is the first point in the process where the individuals involved may decide that the project does not make sense and should not continue. It is imperative that everyone agrees to move forward at this point in order to prevent misunderstandings later in the project. The creation of application prototypes during the Envisioning Phase can help the team reach a clear understanding of the product vision.
Vision approval signals that members of the project team, the customer, and key stakeholders agree on:
In summary, the true goal of the Envisioning Phase is to create a clear consensus on the product vision between all team members and project stakeholders. Once the product vision is understood, the team and stakeholders can agree and commit to it. Understanding, agreement, and commitment to the vision will place the team in an excellent position to move into the Planning Phase.
We've all heard the saying "Plan the work, then work the plan." However, daily pressures and deadlines often preempt adequate planning. Proper planning is ensured by following the MSF Development Process Model.
Why is planning so important? For a very simple reason: It costs less to fix design defects early in the development process. Figure 4.6 illustrates the relative costs of fixing design defects during the four phases of the MSF Development Process Model. As the diagram clearly illustrates, early planning pays off in the end, by reducing the cost in time and resources of fixing defects caused by a lack of good planning.
Figure 4.6 Repair cost of design defects by phase
Although some teams risk failure by planning too little, others risk failure by planning too much. It is important to avoid "analysis paralysis." Good planning is necessary, but it's also important to know when to stop planning and move on. As a general rule, the amount of planning necessary for a given project is a function of both its size (lines of code or function points) and the critical nature of the project.
The application's architecture is defined during the Planning Phase. This application architecture, as noted in Chapter 2, is based on the Conceptual, Logical, and Physical Design Models, which we discuss in detail in Chapter 6. Additionally, the modern approach of multi-layer or N-tier architecture provides a solid and scalable product design that can be implemented as a monolithic, client/server, or N-tier application.
As we mentioned in our discussion of the Envisioning Phase, every project presents three variables with which the team must work. These three variables—schedule, resources, and features—are illustrated in the tradeoff triangle shown in Figure 4.7. These variables are more clearly defined during the Planning Phase, and by the end of that phase, the team has determined the schedule it will meet, the resources it will use, and the features it will build.
Figure 4.7 Tradeoff triangle
During the Planning Phase, the initial balance of the three tradeoff variables is set. The challenge while moving forward into the Developing Phase is to maintain this balance. We discuss the tradeoff triangle in greater detail later in this chapter.
The Planning Phase culminates in the Project Plan Approved Milestone, which is the point at which the project team, the customer, and key project stakeholders agree on the project deliverables. This milestone provides an opportunity to establish priorities and set expectations, and serves essentially as a contract between the project team and the customer. Upon completion of this step, the team can move forward to build a solution.
The deliverables at this milestone are:
For most projects, another deliverable of this phase might be a proof-of-concept system that helps the team and stakeholders understand the application's architecture. Additionally, any significant design concerns can be tested with the proof-of-concept system before the Project Plan Approved Milestone is reached.
Reaching this milestone means that the project team, the customer, and key project stakeholders agree on:
By now, some developers will be eager to "crank out some code." As we'll demonstrate in a moment, that's just what the team has been preparing to do in both of the preceding phases. In the Developing Phase, however, the most important task is to build the application.
Part 3 of this book is devoted to the Developing Phase and the various ways and means of approaching it. For now, let's just say that the work of the Developing Phase should be much more straightforward as a result of the work done in the Envisioning and Planning Phases. It's common wisdom that it's much easier to build an application when a clear set of expectations and a properly defined and tested product architecture exists.
Versions, which have been used during the earlier phases, become even more important during the Developing Phase. The team can expect to do multiple versions of the application during this phase. These application versions, which are typically named alpha, beta, and scope-complete release, will be discussed in detail later.
Additionally, all known bugs should have been addressed by this phase. Addressing known bugs does not necessarily imply that all the bugs have been fixed; merely that they have been investigated. The goal of the Developing Phase is to deliver an application that meets all stated expectations and is ready for external testing.
The Developing Phase culminates in the Scope Complete Milestone, when all features are complete and the product is ready for external testing and stabilization. This milestone is the opportunity for the customer, users, operations and support personnel, and key stakeholders to evaluate the product and identify any remaining issues that need to be addressed before it ships.
The deliverables of at this milestone are:
At this point in the project, the team should have completed development and functional testing for all the product's features. Additional optimization of feature code can continue, and new bugs can be discovered and addressed, during the Stabilizing Phase.
Reaching this milestone means that the development team will create no new features and that the project team, the customer, and all key stakeholders agree on:
Good development teams have known for years that testing should be a major part of any project. Unfortunately, many developers don't adequately test their solutions. They may believe that their code is so good that it needs no testing, or they know that their work was so rushed or ill-conceived that they are afraid of testing it.
Experienced developers realize that software is never error-free. They also know that only good testing procedures can minimize software errors. Experienced developers not only expect testing, they demand it.
It is important to properly set the expectations of the user community at the beginning of this phase. Pilot deployments should be designed to identify performance and environment issues. After these issues are addressed in subsequent bug fix releases, the final product will be deployed.
The functionality of the code is tested during the Developing Phase. However, significant performance and environmental testing occurs during the Stabilizing Phase. During this phase, all known issues are resolved before delivery, and any tasks needed for support and ongoing maintenance of the product are completed. This phase seeks to tie up the loose ends. Documentation, release notes, final "bug stomping," product hand-off, and product deployment are all part of this phase.
The Stabilizing Phase starts when the team shifts its focus from code development to stabilizing and shipping the product and ends when the customer accepts the product as complete. A significant aspect of this phase is that the customer and users begin significant testing of the product. This phase is also the training ground for the organization's operations and support teams. During this time, Logistics Management works to ensure a smooth transfer of product support to the organization's internal support groups, with the product release completing the transfer.
The Release Milestone is reached when the team has addressed all outstanding issues and ships the product, placing it in service. At the Release Milestone, responsibility for ongoing management and support of the product officially transfers from the project team to the operations and support groups.
The deliverables of this milestone are:
By now, the product is fully operational and ready to ship. The Release Milestone signifies agreement by the project team, the customer, and all key stakeholders on:
Immature development organizations often minimize the first and last of the four phases of the MSF Development Process Model. Early analysis of the development task noted that two essential steps are common to the development of computer programs: analysis and coding. These steps correspond almost directly to the second and third phases of the MSF Development Process Model: the Planning and Developing Phases.
For a development organization, or any specific project team, to move from an immature state to a mature one, the organization must pay adequate attention to the Envisioning and Stabilizing Phases. Both of these phases feature increased interaction with the customer and others outside the traditional development team. A development team that does not relate to non-developers will never realize its full potential.
One of the advantages of the MSF Development Team Model discussed in Chapter 3 is that certain team roles are responsible for customer and user interaction. Use of that model ensures that the project team cannot gloss over the Envisioning and Stabilizing Phases. Use of the MSF Development Process Model also ensures that interaction with non-developers is approached in a professional and organized manner. The team should be motivated by the simple fact that the success or failure of the project depends on the attention given to each phase, not just to analysis and coding.