The guidelines we give here are modified versions of those outlined by Laurie Litwack, who has worked on operating systems, server applications, and networking subsystems.
At the beginning of the Envisioning Phase, the project team is selected and members are assigned to lead the six team roles. (Refer to Chapter 3 for guidelines about how to choose a team and how to work with large and small teams.) Each of the team roles plays an important part in the Envisioning Phase, so each must be represented.
Table 5.1 identifies some specific team role responsibilities for the Envisioning Phase. The lead for each team role ensures that these responsibilities are carried out and communicates with the rest of the project team.
Table 5.1 Team roles and Envisioning Phase responsibilities
Role | Responsibilities |
---|---|
Product Management | Deliver Vision Document Manage customer expectations Involve customer in prototype development Manage project risks |
Program Management | Develop design goals Describe solution concept Outline project structure Manage project risks |
Development | Design prototypes Outline development options Identify implications Manage project risks |
User Education | Identify user performance needs and implications Manage user expectations Involve user in prototype development Manage project risks |
Testing | Develop testing strategies Specify acceptance criteria Design bug-tracking system Design risk management system Manage project risks |
Logistics Management | Identify deployment implications Identify support implications Manage project risks |
As the table shows, each role is involved in the task of managing project risks. The process of risk identification and management is discussed later in this chapter.
Several steps can be identified to help the team during the Envisioning Phase. These steps are similar to the Unified Process workflows, discussed in Chapter 4. We don't mean to imply that following these steps is the only way to complete the Envisioning Phase, but to provide a guideline for those new to the MSF Development Process Model. The headings are for descriptive purposes only; they are not intended as formal declarations of procedures or workflows. Additionally, these steps are sequential but should be followed in a flexible manner. For example, if the team is working on Step #4 (the implementation step) and realizes additional use cases are needed, it can return to Step #2 to develop the new set of use cases.
For the vision to be complete, the team needs to do some research, focusing its efforts on the customer and on other similar products being developed by or used by the organization. The goal of this step is to identify and record as much information as possible. Sources for this information should include the project customer, users, current applications and their documentation, as well as experts in the application's area or focus (domain), such as distribution or manufacturing. The team should limit notations about priorities to those obtained from these sources; additional prioritization will occur later. Using this information, the team can ultimately create a vision that outlines priorities, identifies dependencies, and roughs out a schedule.
If a previous version of this product exists, the team should start by understanding that version's vision. It's likely that the previous vision will include long-term goals for future versions that can and should be leveraged. Likewise, the team needs to understand the visions of any other applications concurrently under development.
Some of the questions to be asked when creating a vision for the new product include:
Throughout this book, we continually stress the importance of knowing and understanding the customer and the customer's business requirements before beginning any kind of development work. The Envisioning Phase is the time when the team focuses on the customer's problem and how users will work with the product to solve that problem. Areas the team should address include the following:
The vision the team develops for this product must fit with the visions already developed for the other products used by the organization. In some ways, this is the easiest type of research, because it's a matter of leveraging existing knowledge and working with existing contacts within the organization to ferret out information that already exists. Questions the team should ask include the following:
Synthesizing the business and user requirements gathered in the research step is by no means an exact science. One of the ways to boil down the information is to group it into simplified statements or questions with their solutions. For example, "The consulting group must enter hourly data in three different locations" and "The consulting group wants to enter data only once." Often one side of the equation can be stated, and the team has to determine the other side. The concepts presented on one side represent the current state, and the concepts presented on the other side represent the future state. Looking at a list of the organization's overall business goals can also help the team requirements for a project.
In Chapter 6 we discuss noun-verb concepts for determining logical and physical designs. Looking for key noun phrases and verb phrases can also be useful in identifying project requirements. If project stakeholders repeatedly use the same nouns and verbs when talking about the project, those phrases are probably important requirements for the project.
Business and user information can be analyzed to create product feature lists. As with requirements, the derived features should not have a scope or version applied to them at this point. The team will determine the current product's actual feature set, and some feature sets for future releases, in the implementation step discussed below.
To help document business and user requirements, UML use case and activity diagrams are very helpful for concisely communicating information. The use case model of the Unified Process can be used to describe the requirements in the language of the users. Additionally, simple word descriptions (typically in sentence form) of the specific use cases, as well as descriptions of usage activities and usage scenarios, provide good communication of requirements. When this step is complete, the team should have an exhaustive list of use cases, which will be the foundation of the entire development process.
After the use cases and feature lists are created, those features that are similar in nature can be grouped into feature buckets, or sets of features, based on user actions, application actions, the data being used, or any other grouping that applies to the application's domain. At this point, the team is still working with features that describe current state as well as future state. For current state activity descriptions, the team can apply process re-engineering techniques to determine whether the activity can be modeled more efficiently in another manner. The design patterns discussed in Chapter 2 can provide examples of different and better ways to model processes in an application.
As each step of research, analysis, and rationalization is completed, and as any prototypes related to the category are developed, what has been learned is recorded so that over a period of time, a body of documentation about the project accumulates. In the research step, the team's job was not to analyze the information, but simply to record the information as it was encountered. During the analysis step, the research was refined into actual business and user requirements described by use cases, and candidate features were listed. The rationalization step grouped features into feature buckets. The final step is to determine what specific feature buckets will be implemented for the current product version.
At this point, the team prioritizes the feature buckets, with their corresponding features. The future-state use cases, use case diagrams, activity diagrams, and usage scenarios that describe this release of the product are gathered together, and a project vision is drafted. This draft includes the long-range goals for the project and validates that the current product version is moving in the right direction. At this point, enough information is known to determine how the product's tradeoff triangle of resources, features, and ship date is constrained, optimized, and accepted. The initial high-level project schedule can also be determined to provide guidance and reference for the Planning Phase.
As mentioned, the team created the draft of the Vision Document during the Implementation step. The team now reviews and modifies this document. The Envisioning Phase's validation step is the point where the team members need to take a step back and look at their progress and deliverables to ensure that they are adequately prepared for the Vision Approved Milestone.
The envisioning process in not about creating documents; it is about communicating the vision of the project within the project team and with the project stakeholders. Prototypes are an excellent method of communication. At the heart of any prototype concept is the old adage "A picture is worth a thousand words." The level of detail in a prototype application is typically very shallow. It may consist of nothing more that screen shots or examples of typical screens. However, the application flow can be described by stepping users through a prototype that follows one of the use cases or usage scenarios defined by the team.
CAUTION
Don't expect to reuse significant amounts of code from a prototype. Reuse often leads to jumbled "spaghetti" code that limits the application's design process.