Review:The Unified Software Development Process

Thanks to SEGV for the this review of Jacobson, Booch, Rumbaugh's latest effort The Unified Software Development Process. A book designed for those of you who love process (or want to learn development process), click below for more information. The Unified Software Development Process author Ivar Jacobson, Grady Booch, and James Rumbaugh pages 512 publisher Addison-Wesley Publishing Co. rating 8/10 reviewer SEGV ISBN summary A textbook treatment on process in software development. Covers the Unified Process from product launch to architectural baseline, through initial operational capability, ultimately to product release. Information rich but occasionally dry.

The Unified Process

This book is the third by the Three Amigos this past year (the other two being the UML user and reference guides). Although recently known for their work on the UML at Rational, the Unified Process is an outgrowth of Jacobson's original work at Ericsson on the Objectory Process.

So what is the Unified Process? I'll quote from the book's glossary:

A sofware development process based on the unified modeling language that is iterative, architecture-centric, use-case driven, and risk-driven. A process that is organized around the four phases: inception, elaboration, construction, and transition, and that is further organized around the five core workflows: requirements capture, analysis, design, implementation, and test. A process that is described in terms of a business model, which in turn is structured in terms of three primitive building blocks: workers, activities, and artifacts.

Essentially, this is the 463 page textbook elaborating on what was briefly described in the second chapter of Martin Fowler's UML Distilled [related review].

Organization

The book itself is well organized. Chapters are broken into logical sections and bite-sized subsections. For example, most chapters in Part II follow this structure: introduction, role, artifacts, workers, workflow, summary, and references. That consistency is a boon to the reader (and not an albatross, as it is deviated from where necessary).

Figures help the reader to maintain a frame of reference (e.g., traveling through the phases and workflows). This is important as the Unified Process can occasionally be confusing, with its repeated iterations and workflows.

The authors provide examples where illustrative and references where beneficial. The appendices are handy, especially the 13 page overview of the UML (which is very well done).

Impartiality

One of my concerns reading this book was the degree of impartiality of the authors. Naturally, being Rational employees they have a vested interest in promoting their Unified Process and UML tools. Happily, I didn't notice an overt conflict of interest. Rational is mentioned a few times, but not obtrusively. And although they mention tool support as being an imperative, that's probably true.

Another area of impartiality is in their references. The authors don't reference their own works exclusively, but instead point the reader in other fruitful directions, including the design patterns literature and even Peter Drucker's writings on management theory.

Impressions

I found that the authors often had useful things to say. Whenever I open to a random page, I find a useful tidbit or two, and I appreciate that. There's nothing radical here, but the structured presentation benefits the content a lot.

This is a book on software process, and a fairly textbook-ish one at that, so I wasn't surprised to find the writing a little dry. In particular, I found the chapters in Part II to be particularly soporific on first read, but then I realize that the internal mechanics of software development don't necessarily make for the most thrilling read. Returning to those chapters to read in measured dosage really does them well.

Minor Drawbacks

I'd like to have seen a little more variation in the examples. I remember quite a few dealing with bank machines, and although that leads itself to a certain stability, it can be hard to get excited over such applications.

Although the index is fairly complete, I recall one omission in particular. The authors discuss three ways the Unified Process addresses the issue of "good enough" software, yet no mention is made in the index. That piqued me when I wanted to look it up.

Finally, although the authors use C++ and Java for the occasional lower level example, they use a directory as a packaging mechanism in the former. I feel a namespace is more applicable.

Applicability

While I was reading this book, I was preparing documents and presentations on software process for my employer. I did find this book to be helpful, and definitely feel that it was a worthwhile read.

This is not a recipe book. It won't lay down everything for you. But it will get you started thinking in the right direction, and aware of the issues involved in an industrial strength software development process.

However, it's important to remember that the Unified Process is not the answer to all process questions. Although it scales well, I believe it can be overkill for small teams, and I assume inadequate for some larger organizations as well.

Recommendation

If process is your thing, then you'll probably want this book. If you lead a team in a medium sized software development organization, and are interested in introducing a more formal process, then this book is a recommended read. Even if you don't end up applying the Unified Process, it simply addresses too many relevant details to be ignored.

I don't recommend this book for casual reading, unless you have an interest in process. A good example might be a developer in a medium sized organization who feels they need a more formal process. A good guideline might be whether you're still interested after reading the glossary quote in the introduction.

You will find the book web page in Addison-Wesley's Object Technology Series.

Purchase this book at Amazon.

TABLE OF CONTENTS

Preface
Part I: The Unified Software Development Process
1. The Unified Process: Use-Case Driven, Architecture-Centric, Iterative, and Incremental
2. The Four Ps: People, Project, Product, and Process in Software Development
3. A Use-Case-Driven Process
4. An Architecture-Centric Process
5. An Iterative and Incremental Process
Part II: The Core Workflows
6. Requirements Capture: From Vision to Requirements
7. Capturing the Requirements as Use Cases
8. Analysis
9. Design
10. Implementation
11. Test
Part III: Iterative and Incremental Development
12. The Generic Iteration Workflow
13. Inception Launches the Project
14. The Elaboration Phase Makes the Architecural Baseline
15. Construction Leads to Initial Operational Capability
16. Transition Completes the Product Release
17. Making the Unified Process Work
Appendix A: Overview of the UML
Appendix B: The Unified Process-Specific Extensions of the UML
Appendix C: Glossary
Index