Good Beginnings
Lao Tzu said, “A journey of a thousand miles must begin with a single step.” However, if you are going a thousand miles, that first step better be in the right direction. The following topics will help you set your direction, decide your priorities, and choose good traveling companions.
The Elephant
Remember the old joke that asks, “How do you eat an elephant?” (answer: “One spoonful at a time.”)? Just as that joke suggests, adopting the UML is not an all-or-nothing proposition. You do not have to know the entire UML to be able to use it. Remember, according to Booch, Rumbaugh, and Jacobson, “You can model 80 percent of most problems by using about 20 percent of the UML.” [BOOCH1]
So, where do you start using UML on your projects? Given that you are not taking the full leap into UML for your entire project (which is a valid but challenging approach), one way is to adopt the UML based on need. Where do you need the most help? If your organization has difficulty satisfying or understanding your customer's needs, you can start by using use cases to work with those customers to elicit their requirements. If you need to redesign business processes, activity diagrams can help you understand the current processes and design the new ones. If your application developers and database developers don't communicate well, you can create your conceptual, logical, and physical database designs using UML. If you want to adapt UML incrementally, pick the area in which you have the greatest pain and use the UML to help improve that area. After you resolve that problem area, move on to the next, and so on—one spoonful at a time.
Use Cases and Risk Management
System and software development is inherently a risky business. Numerous studies over the years have reported what most of us have experienced—that most projects fail when measured against cost, capability, and/or schedule. One way to manage this risk is to drive your program with use cases.
After you define your use cases (for this exercise, having a good definition of each use case is sufficient—the detailed scenarios don't have to be fully defined yet), rank them based on how important they are and how difficult they will be to implement on a numeric scale of your choice; 1–10 is acceptable. Then plot the use cases as a scatter plot (see Figure 9-1).
Figure 9-1. Scatter plot of use cases.
Next, partition this plot into four quadrants (see Figure 9-2).
Figure 9-2. Scatter plot quadrants.
The upper-right quadrant (see Figure 9-3) displays the important but difficult use cases. These are your high-risk use cases. Develop these first because if you are unsuccessful with these, your project fails. Any other work you do on the unimportant use cases will be a waste of time and money.
Figure 9-3. Develop high-risk use cases first.
The upper-left quadrant (see Figure 9-4) contains the use cases that are important but not as difficult as those in the upper-right quadrant. Of the remaining use cases, these provide the most value to your customer. Develop these next.
Figure 9-4. Develop remaining important use cases next.
The lower-left quadrant (see Figure 9-5) shows the use cases that are not as important but that also are not difficult to implement. If you have time and resources, develop these next.
Figure 9-5. Develop these easy use cases third.
The lower-right quadrant (see Figure 9-6) contains the unimportant yet difficult use cases. They provide little value for the effort you will expend. Do these last. If you get into a schedule or resource crunch, dump these first.
Figure 9-6. Develop the remaining use cases last, if at all.
Recruits
Even if you follow these tactics, your success still boils down to the people you pick to learn UML and OO techniques. Management often mistakenly assumes that programmers make the best OO designers. This is not necessarily true. You need two key skills to succeed in the OO arena: the ability to think in an abstract way (being able generalize specific ideas to a higher abstraction level in order to create resilient, flexible systems), and the ability to thoroughly analyze problems and synthesize solutions.
In our experience, in any random selection of candidates who might or might not possess these two skills, only 25 percent will immediately understand the concepts and value of OO analysis and design, and 33 percent won't understand it at all and most likely will reject UML/OO concepts outright. As for the remaining people, they will somewhat understand and accept the concepts. (This last group would particularly benefit from mentors so that they don't go down the wrong path with their designs; see the next section.)