Approach Used in This Book

As you may have already deduced from the depth of the process descriptions given thus far, the approach in this book is largely based on the RUP.

The decision to do so was based on the following:

• The RUP is a proven process and is currently being used successfully in a large number of projects.

• We strongly believe that architecture, analysis, and design are essential to a project's long-term success. Unlike other processes, for example, FDD and XP, the RUP provides excellent coverage of these key aspects.

• There are enough similarities between the RUP and other processes (e.g., ICONIX) to make the work presented in this book useful to even those not using the RUP in its pure form.

• The RUP can be customized to suit specific needs.

Of course, this decision was not based, by any means, on an exhaustive comparison of the different approaches and was no doubt influenced by our own familiarity with the RUP.

We should point out that in this book, we have chosen to use a customized version of the RUP tailored for the needs of this specific book and case study. In addition, we do not attempt to cover each and every artifact, deliverable, or element outlined in the RUP. This is primarily due to space and time limitations imposed by the book.

For instance, we condense what would realistically be done over several iterations with multiple increments, each into a seemingly single iteration. We also do not cover all disciplines identified in the RUP, limiting ourselves to those most directly relevant to illustrating specific aspects of analysis, design, and development.

Figure 5-4 graphically illustrates the relationship between the different RUP workflows, artifacts produced during the workflows, and how the chapters in this book relate to them.

Refer to the References section at the end of this book for additional sources of information about the RUP.