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

Comments

Re:Three Amigos and the web era

[Chris Parrinello]

What if you have to write a large web application?

Basically, what you're saying is that you don't have to rewrite the foundations of a web server to have a web application. Okay, I agree with you but still there is a lot of work involved in large applications to model the business process, analyze requirements, create an architecture (yes, architecture is more than just picking which web server to use), etc.

Granted, you don't need to do all of the artifacts in all of the development phases for a project but UML still has a place in most OO projects. If you are working in a team, the diagrams are best for communicating how the application will work and will be structured. If the application will be enhanced at a later date, you have a collection of documentation (through UML) that hopefully will make it easier which classes would have to be modified, which use cases and scenarios have changed, etc.

And if you get hit by a truck the UML documentation will allow whoever replaces you to make heads or tails of your code. Sometimes comments just don't cut it to see the overall interaction between objects.

Question: Trivial examples ?

[MeerCat]

>> 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.

Rumbaugh's "classic" book was overly simplistic, and Booch's "management overview" book suffered from the same. They're great at describing "tangible" object systems (hot water systems, vehicles etc.) and systems where the major classes are obvious (customer, account, transaction, etc.), but fall apart on real-world examples of abstract problem spaces. I know these "physical examples" are easier to use as illustrations (familiarity of the reader etc.) but they assume that all problems are like this.

Is the new book any better, or are they still relatively naive ?

If not, I'd recommend DeGrace and Stahl ("Wicked Problems, Righteous Solutions" and "The Olduvai Imperative: CASE and the State of Software Engineering Practice") as balancing the hype of all those processes which feature steps like "and then a design miraculously appears". Maybe I should pull my finger out and submit a review ;^)

Waterfall Design?

[HarpMan]

I've just started reading the book, so I can't really comment on it. I do have a question, however, for those who have read it.

Does this book effectively address how to effectively implement an iterative process, as oppossed a waterfall process? A lot of contemporary methodologies pay lip service to the idea of iterative design and development (with lots of recursive arrows on the process diagrams), but this is often very difficult to implement in a corporate environment. (Easier on web-based/open source projects.) On my projects where I own everything, I constantly go back and revise specs. But on a large coporate project, changing the spec can be a big deal and take a long time, so it tends not to get done -- once the spec is written, it's set in stone. I suppose tools would help here.

Also, how do the authors feel about using UML tools like RationalRose for code generation? It seems like that could be pretty handy, but I worry that people would start using the diagrams as an implementation tool, instead of a design illustration tool. The diagrams could get too complicated, and hard to understand. What Fred Brookes said about flow-charts might apply here -- a little bit goes a long way. One simple, unclutterd UML diagram could be more useful than lots of really complicated diagrams.

------------------------------