Chapter 2. An Outline Development Process

The UML is a modeling language, not a method. The UML has no notion of process, which is an important part of a method.

The title of this book is UML Distilled, so I could have safely ignored process. However, I don't believe that modeling techniques make any sense without knowing how they fit into a process. This is why I decided to discuss the process first, so you can see how an object-oriented development works. I call it an outline process because rather than trying to go into great detail, I'm offering just enough to give you a sense of the typical way in which a project that uses these techniques is run.

The three amigos have developed a merged process called the Rational Unified Process. (It used to be called Objectory.) This process is described in the amigos' process book (Jacobson, Booch, and Rumbaugh 1999).

As I discuss the outline process, I will use the terminology and outline framework of the Rational Unified Process. (I have to use something, and that seems as good as anything.) However, I have not tried to describe the Rational Unified Process; that is beyond the scope of this book. Rather, I'm describing a lightweight, low-ceremony process that is consistent with Rational's process. For full details on the Rational Unified Process, you should go to the amigos' process book or see Kruchten's overview (1999).

Although the Rational Unified Process contains details about what kinds of models to develop at the various stages in the process, I won't go into such details. Nor will I specify tasks, deliverables, and roles. My terminology is looser than that of the Rational Unified Process that is the price one pays for lightweight description.

Whatever process discussion there is, don't forget that you can use any process with the UML. The UML is independent of process. You should pick something that is appropriate for your kind of project. Whatever process you use, you can use the UML to record the resulting analysis and design decisions.

Indeed, I don't believe that you can have a single process for software development. Various factors associated with software development lead you to various kinds of processes. These factors include the kind of software you are developing (real time, information system, desktop product), the scale (single developer, small team, 100-plus-member team), and so forth.

I believe that teams should grow their own processes, using published processes as advice rather than as standards to follow.