Establishing the Project Vision
Remulak Productions is the subject of the sample project that will unfold throughout the remaining chapters. A very small company located in Newport Hills, Washington, a suburb of Seattle, Remulak specializes in finding hard-to-locate musical instruments—in particular, guitars—ranging from traditional instruments to ancient varieties no longer produced. Remulak also sells rare and in-demand sheet music. Further, it is considering adding to its product line other products that are not as unique as its instruments, including recording and mixing technology, microphones, and recordable compact disk (CD) players. Remulak is a very ambitious company; it hopes to open a second order-processing location on the East Coast within a year.
Most of Remulak's orders are taken in-house by order entry clerks. How ever, some of its sales come from third-party commercial organizations. Remulak's founder, owner, and president, Jeffery Homes, realizes that he cannot effectively run his company with its current antiquated order entry and billing system. Our challenge is to design and implement a system that not only meets the company's immediate needs but also is flexible enough to support other types of products in the future.
The first step is to identify the features that the application needs and to scope the project. The vision will define the boundaries of the project and limit the possible features, as well as implement the housekeeping framework that will guide the project forward. Appendix A contains the project plan templates found in the Unified Process. Before beginning, however, let's reorient ourselves to the Unified Process.
The Process Model
Recall that the Unified Process is our guide to performing activities in a predictable order. Figure 3-1 shows the Unified Process model from Chapter 1, with the Inception phase highlighted.
Figure 3-1. Unified Process model: Inception phase
The goal of the Inception phase is to “go a mile wide and five inches deep” through the entire system. Upon completion of the Inception phase the project team will have an idea of the following:
The goals of the system from the perspective of the stakeholders
The events the system must support
The use-cases that make up the system under discussion
The use-cases and/or use-case pathways that are architecturally significant
A high-level phase plan for the four phases of the project (Inception, Elaboration, Construction, Transition) and a detailed iteration plan for the architecturally significant requirements identified in the previous step
In this chapter the following Unified Process workflows and activity sets are emphasized:
Working Template of the Project Vision
The project vision is the key deliverable of the Inception phase. It is much more than a superficial document that merely mentions objectives and desires. It lists the events, first-cut use-cases, and architectural components that the project will support. And it is a vital step toward our understanding the requirements of the application.
We can best describe the project vision by outlining a proposed template that covers, at a minimum, the topics listed in Table 3-1.
To provide some of the artifacts identified in the project vision, we need to explore deeper the factors that constitute the essence of the application: actors, event lists, and event tables.
Actors
Actors are key to obtaining several artifacts in the project. Actor is a term coined by Ivar Jacobson in his OOSE (Object-Oriented Software Engineering) approach to software development (originally called the Objectory Process and now called the Unified Process). Actors are essential in the project. Identifying them gives us better insight into the events that the system must support.
| Topic | Purpose |
|---|---|
| Business purpose | The business reason for undertaking this project. |
| Business objectives | The business objectives of the project. What bottom-line benefits will the project bring to the organization (e.g., the ability to remain competitive, profitable, leading edge, reactive)? |
| Desired features | The features that the project must support (e.g., order tracking and control, expedient billing, management of inventory, one-day turnaround on special orders). |
| Critical success factors | The key factors that will make the project a success (e.g., delivery of products on time and within budget, hiring of a talented project manager, reassignment of skilled analysts and developers from existing projects, acquisition of full-time user commitment). |
| Constraints | Constraints from time, cost, and functionality perspectives (e.g., the project must be completed by year's end, provide a payback within two years, implement a minimum of usable functionality before going into production). |
| Risks | The clear risks of the project (e.g., the project team has never used Java Basic, let alone object-oriented programming techniques and UML, the existing system will prove difficult to convert because of its antiquated design, the executive sponsor is giving only lip service to full-time user involvement). |
| Roles and responsibilities | The logical functions that will be performed and by whom (e.g., Executive Sponsor: Jeffery Homes, Lead Analyst: Rene Becnel, Lead User: Dan Fruge, Lead Designer: Todd Klock, Lead Architect: Jose Aponte). |
| Locations of interest | The geographic areas (if any) that will be expected to use the applications (e.g., New Orleans, Denver, Seattle). |
| Stakeholders/actors | Entities that stimulate the system in one form or another. They are usually actors human beings, but they might also be other systems, timers or clocks, or hardware devices (e.g., order clerk, billing clerk, shipper, accounting system, bar-code reader). |
| Event list/event table | Outline of the essential events that the system must be aware of and that will provoke a perceived system response. It might also be good to specify location, frequency of arrival, and arrival pattern (e.g., customer places order, customer inquires about order status, order is shipped, order is billed, order is back-ordered). The event list is delivered in the Software Requirements Specification (SRS) but is kicked off during work on the project vision. |
| Use-cases | The use-cases that represent the major goals of the application. These are delivered in the Software Requirements Specification (SRS), but they are kicked off during the work on the project vision. The use-cases will be reviewed in Chapter 4. |
| Preliminary execution architecture | The architecture that is initially envisioned for the construction and production maintenance of the application (e.g., Java over a TCP/IP wide-area network [WAN] using an multitier design approach). The database will initially be Microsoft SQL Server, but all data access will be made via Java Database Connectivity (JDBC) drivers to allow the appli cation to migrate to a different relational database management system (RDBMS) in the future. Visual SourceSafe will be used for source control, and Microsoft's Systems Management Server (SMS) will be used to distribute software components to remote locations. |
| Project infrastructure | Details of how change control and risk assessments will be made (e.g., all changes will be tied back to the original event table, and any changes not defined within that event table will have to go through a change control procedure). |
| Project release strategy | Planned release strategy for the project, indicating the increments, duration of each, and anticipated implementation schedule (e.g., there will be three increments for the project: (1) order entry and maintenance, (2) billing, and (3) inventory management). |
Actors are usually thought of as human beings, but they may also be other systems, timers and clocks, or hardware devices. Actors stimulate the system and are the initiators of events; they also can receive stimuli from the system and in this case are considered passive. They are discussed in more detail in Chapter 4. For now, they are represented as they are identified in UML, as stick figures, as shown in Figure 3-2. However, they may also be rendered graphically in other ways that more directly illustrate the specific domain of the application.
Figure 3-2. Examples of the actors of a project
Too often, people attempt to understand a project by producing reams of paper describing what the system will support. This is a wasted exercise that we can remedy by first focusing on the actors—that is, the users—involved in the system. To find the actors, ask the following questions:
Who/what will be interested in the system?
Who/what will want to change the data in the system?
Who/what will want to interface with the system?
Who/what will want information from the system?
Be careful to focus specifically on the role that each actor will play. This is very important because a given person might play more than one role. As we uncover more information about how the actor interfaces with the system, lumping all of these roles together and treating them as the roles of one actor could be a mistake because that actor might not always play those multiple roles.
Logically, different roles might require different interface skills, knowledge of the system, and comprehension levels. We would err if we designed the interface on the basis of an assumption that the actor is superhuman and can cover lots of bases. Rather, we should analyze the role that each actor plays in the system. This approach will certainly make the system more pliable if the actor's responsibilities change.
Table 3-2 lists the proposed actors for Remulak.
| Actor | Definition |
|---|---|
| Customer | Places orders for products. |
| Supplier | Supplies products to the company for resale. |
| Accounting system | Gets accounting information from the system. |
| Billing clerk | Coordinates and tracks all sales from a financial perspective. |
| Shipping clerk | Coordinates the routing of fulfilled product orders. |
| Packaging clerk | Prepares the product for shipment. |
| Order clerk | Takes new orders and maintains existing orders. |
| Customer service clerk | Serves customers. |
| Manager | Requests reports on the status of the company's orders. |
Now that we have identified the actors, we'll explore the events that they are responsible for generating.
Event List and Event Table
The event list is the catalyst that flushes out use-cases—something we will do in Chapter 4. Use-cases are not always intuitive. Events, on the other hand, are easy to identify and are very much on a project sponsor's mind. Once the events have been identified, the definition of use-cases is easier. You won't find an event list category in the vision template offered by the Unified Process, but I find it invaluable to the process.
The event list can be created separately from the event table, but one leads to the other. The system must be aware of many types of events. Typically, events fall into two categories: external and internal.
External events are the easiest to find. They are any stimuli to the system that originate from outside of the system's boundaries (e.g., the placement of an order by a customer). To identify external events, focus on the event and ask the question, Who or what is stimulating the event? Most events that we will identify are external.
Internal events are more diverse. One type, and the only one that we will identify now, is the clock or timer event. I view this type of internal event as “that big timer in the sky that goes off, causing the system to do something.” Internal timer events are very common in most systems, across all types of domains. Examples of events that are stimulated by an internal timer are Produce backorder reports nightly and Interface with the general ledger system every two days. Again, focus on the event and ask the question, Who or what is stimulating the event?
Other types of internal events, which we won't discuss here, are those generated by the system. These events typically fall into the category of certain limits being reached or objects being created or deleted. For example, consider the following criterion: If a customer's credit is exceeded, we need a supervisor's approval to complete the sale. That the credit is exceeded is an event; however, this type of event will be specified as a business rule that is owned by a class in the domain.
Let's briefly examine the notion of business rules because they will come up quite a bit while your team is creating the event list.
Identifying and Categorizing Business Rules
The term business rule got quite a bit of attention in the 1990s. Entire seminars were devoted to the subject. Many practitioners—most notably Ronald Ross—did considerable work in this area.
At this point, some of you might be wondering why we're worrying about business rules. The reason is that they will come up quite often during the event-gathering process. It's a good idea to have a feel for what they are and how to categorize them. When I facilitate an event-gathering session, I usually have a separate easel on which I list the rules when they come up. Our goal is to categorize rules about the business that naturally arise during the Inception phase and that continue into the Elaboration phase.
Business rules can be categorized as follows:
Structural fact: Requires certain facts or conditions to be true; for example, each order must have an order-taken date, each customer must have approved credit.
Action restricting: Prohibits one or more actions on the basis of its condition; for example, add a new business customer only if that customer has a Dun & Bradstreet rating.
Action triggering: Instigates one or more actions when its condition becomes true; for example, when an invoice is not paid by the due date, assess a one-percent penalty,
Inference: States that if certain facts are true, a conclusion is inferred or new knowledge is known; for example, if a cus tomer incorporates, the customer's status changes to business customer.
Derivation: Performs computations and calculations; for ex ample, the total value is the sum of all past orders plus the additional amount derived from the current order.
These categories are not hard-and-fast, but they do provide a method for gathering business rules. You can add additional categories to provide more granularity if you desire.
Event Capture Format
Sometimes project teams struggle with which external events to include in the project's scope. To help make this decision, ask if the system would be stable if you chose not to respond to the event. For example, the event Customer Places Referral Order might be a valid event; however, it is out of the scope of this project. An event that is critical to the integrity of a system, such as keeping creditworthy customers, isn't something that could be implemented optionally.
One last point on external events that might be out of scope: Don't exclude them during this initial brainstorming session. You might be surprised how many times you will revisit the list later, and you might resurrect some events that previously were deemed out of scope. It is a good exercise not to cloud the session with premature assumptions about boundaries. Here's a good maxim to follow: Ask for the sky, prioritize, and then simplify.
Now we can begin identifying the events. Think of an event as following this general form:
where
Subject is an actor defined earlier in the process—for example, customer or shipping clerk.
Verb shows the action, such as places, sends, buys, or changes.
Object is the focus of the action defined by Verb.
Here are some examples:
Customer + Places + Order
Shipping Clerk + Sends + Order Items
Customer + Buys + Warranty
Order Clerk + Changes + Order
It can be helpful to come up with events in one session and then, in another session, focus on adding information and placing the events in an event table. The goal is to get the events into the event table quickly because it is one of the first key artifacts produced as part of the project vision effort.
The event table identifies additional information that will provide important input to other areas of the organization (e.g., operations, network support). Table 3-3 shows a proposed format for the event table.
The importance of the arrival pattern might vary depending on the application domains. The following are typical values for it:
Eventually we will want to be even more specific regarding the granularity of the arrival pattern (e.g., peak hour frequency) because this in formation will be vitally important to the network and operations staff. For example, 1,000 Customer Places Order events in a given day might not concern the network staff, but 900 such events between 8:00 A.M. and 9:00 A.M. definitely will. At this point in the project we might not know this level of detail; nevertheless, we must take a stab at predicting the arrival pattern. In addition, if the locations are known now, the frequency cells in the table should outline them and their unique frequencies.
The anticipated responses are at a relatively high level at this point. However, anticipated responses are an important component of the event table because they represent the expectations of the actors, many of whom are probably members of the project team. These responses will be realized as design components and actual code later in the project.
The Project Vision
In the first pass of the project vision, the project team must agree on the template's basic components (features, critical success factors, and so on), the actors, and the events to be supported. Although this effort can be accomplished in any of several different ways, a facilitated session works best, preferably supervised by a disinterested third party skilled in facilitating and in keeping things on track.
For very large projects, the project team should consider breaking up the sessions by logical subsystem—for example, accounting, billing, and order entry. Whether you do this depends on the size of the project. For example, I once worked with a large automobile company that was attempting to integrate state-of-the-art human interaction technology into the automobile. We broke up the project team into six separate teams along their functional boundaries (e.g., voice, cellular) and gave each team a week to come up with its part of the project vision.
In Chapter 4 we will assign events to use-cases. We will also add detail to some parts of the use-cases before attempting to estimate the project's release cycles (increments) and time frames; we need to know more about the project before we estimate the effort. Two new artifacts will begin to surface: the Software Requirements Specification and the Supplementary Specification. This is where the Unified Process differs from many other processes. (An approach to estimating use-cases is covered later in Chapter 4 and in Appendix C.) It is wise to remember that regardless of the caveats you put on an estimate, people later will recall only the estimate itself.