Customer Reviews

The Unified Software Development Process

5 star:		(9)
4 star:		(9)
3 star:		(5)
2 star:		(5)
1 star:		(9)

 

 

After mastering the Unified Modeling Language, it's a natural progression to apply UML in a documented and time-tested process. That's what the creators of UML set out to describe in this third book of the UML-Big-Three, "The Unified Software Development Process."

Getting through this book will be challenging, though. You'll be thirsty not for more material, but a glass of water by the time you're done. It is bone-dry.

The Unified process has five workflows (requirements, analysis, design, build, test) that repeat within four phases (inception, elaboration, construction, transition). There are unfortunately huge chapters devoted to each of the workflows and each of the phases separately, with only a smaller amount of material focusing on how the process is actually done, which is each workflow occuring in the context of each phase. As a result, the book seems a lot bigger than it needs to be. (I'm not panning the process, though, which does indeed work, just the presentation.)

There's a running example through the text of building an automated teller application. While running examples help unify ideas, they show a narrow view of how the process can work in practice. In applying the process to my projects, it's difficult to translate such a financial application to my work (which is scientific and library-based in nature). I'd like to see a lot more examples that give alternative viewpoints in addition to the running example that demonstrates the process as a whole.

Unlike the other two books of the Big-Three, the diagrams in this one are the best. They're clean, consistent, and easy to read, and there are a lot of them. It's professionally typeset and each page is pretty.

What we need is a book similar to Fowler's "UML Distilled" called "Unified Process Distilled." The process is great---it just shouldn't take 500 pages to describe it.

This book is really a long-winded re-iteration of the obvious. Some sound engineering practices are described in the the book. But, they are not new, and they could easily have been described in 50 - 100 pages instead of almost 500 pages. To make things worse, the book is written in a dull style.

This book also tries to teach some UML from a project manager perspective. The result is not very pedagogic. To learn UML I recommend a book on UML (like "The Unified Modeling Language User Guide" or "UML Distilled") for both project managers and programmers.

If you are looking for information on how to run software projects or on sound software development processes I would recommend "Rapid Development" by Steve McConnel and "Software Project Survival Guide" (also by Steve McConnel). "Rapid Development" provides a better description of the iterative development processes, together with a wealth of other useful information not found in "The Unified Software Process".

I am concerned by the way that the artifacts (documents, models) are presented. There are long lists of artifacts presented as the result of each work-flow and of each phase. I understand that this must be adopted to each organization and each product type. But there is a risk that organizations adopting to "The Unified Software Development Process" end up as bureaucratic monsters, producing documents instead of software. Unfortunately the present "guru" status of the three authors will probably increase this risk.

I have been teaching Systems Analysis for over 30 years. This is the worst textbook I have used in those 30 years. The writing style is atrocious. The sentences are so belabored. In a single sentence one may find parenthetical expressions, references to other parts of the book and conditional expressions. Here's a typical example "However, the elements defined in the design model are the "design counterparts" of the more conceptual elements defined in the analysis model in the sense that the former (design) elements are adapted to the implementation environment whereas the latter (analysis) elements are not".

Need I say more?

Most diagrams are about the USDP rather than diagrams about the artifacts that the USDP requires. Never is there a really good illustration of the blood and guts of the process, a "Use Case".

I had 72 students ready to lynch me. It was the worst mistake I ever made in the textbook selection process.

If you need an academic view on software engineering and the UP in particular, get this book. Otherwise you'll find it useful for occasional reference at best.

If you don't know the UP/RUP, forget about this book and get Kruchten's "The Rational Unified Process--An Introduction"

If you know the UP and need more information about how to apply it in real-world projects, chances are you won't find it in this book. You might want to look into Scott Ambler's series "The Unified Process xxx Phase".

Remember in college how you had some professors who would lecture and some who would teach? This book, unfortunately, isn't about teaching.

The authors have written "The Unified Software Development Process" to the academic OO community, not to students eager to learn OO techniques from the masters. Every reference in this book is footnoted, every historical precedent mentioned, every alternative way of doing something is brought up so it can properly be dismissed. It reads like a Ph.D. thesis.

In other words, the authors seem more interested in pleasing OO academicians than in transferring their experience to OO disciples eager to learn from their years of experience.

Still, I can't fault the actual content of the book. It's a good book, with good content. I just spent way too much time struggling to pull the content out of this book that reads like academic lecture notes.

This book has the worst writing style I have ever seen. The actual process seems very promising, unfortunately this book does not teach the process as much as it defines what the process is and isn't academically in an extremely repetitive and boring way. After reading most of it twice I am just as confused about how to go about conducting the process, and I know little more than what I knew prior to reading the book.

The book definately is geared towards proving the process as better than other ways of doing things and the last chapter is directed toward the process of how one individual can shoe-horn their entire workplace into using the process. With a closing like this, obviously the book was not intended as an aid to learning the actual process as much as it was to give management a fuzzy view of the process without answering a lot of questions which one who is attempting to learn the process will need.

For me, the absolute worst part of the book was the vocabulary. Stereotypes created in the book to describe things with names like "Use case realization -- design" and "Use case realization -- analysis" will undoubtedly get on your nerves after seeing the term used 405 times. Not to mention definitions similar to: An attribute is a property of the analysis model. Gee, an attribute is a property? and a property is an attribute.. now I know everything, time to code.

In summary, if you like to refer to a book as 'the realization of thought instances' and would like to read 500 pages of such descriptions, then this book is for you!

There is not much more to add beyond the title of my review. Jacobson, Booch and Rumbaugh may be the fathers of UP but their writing style is far too academic for the average reader. Keep this book on your top shelf as reference material when you need to clarify a point on UP. But if you need a more manageable understanding of the unified process, buy Philippe Kruchten's "The Rational Unified Process, An Introduction". It's RUP for the common programmer. Another book to buy is Craig Larman's "Applying UML and Patterns: An Introduction to OOAD and the Unified Process". Larman does an excellent job at demonstrating how UP can be used on a real project.

This book defines a process for object oriented software development. Essentially, it could do for the software engineering community, what UML has already done, that is draw together from the best methods and create a well thought out and vivid process. As a book, it clearly explains each essential aspect of the process (Use Case Driven, Architecture Centric, Iterative and Incremental), the steps needed to carry out the process and the 'artifacts' that are the result of each iteration of work. There are plenty of diagrams that back up each explanation, allowing the reader to get the whole picture. The book does require reading from cover to cover if you are not familiar with object oriented development. The book does not cover the software project management aspects in very much detail, leaving the reader to find details of the management aspects (eg Change control and Risk Management) to find in another book that covers these topics (Software Project Management by Royce, which is another book in the Addison Wesley Object Technology Series).

I suppose that students at our school are representative for the worldwide population of cs students. This book is not at all an easy introduction to the unified process. Having been introduced to the principles of ooad in an earlier semester, and thus already knowing something about ooad, we were introduced to Jacobsons RUP. Their book contains a lot of knowledge, but unfortunately the authors are a) either not very good at explaining their knowledge b) hiding the knowledge to make it seem more intelligent than it really is or c) have written the book for people who already knows, at least something, about the unified process, or the objectory process that preceeded RUP. If you are looking for good illustrations and examples on how to model a system with uml and the added classifiers using the the RUP, then I suggest that you don't start with this book. You'll be disappointed. Working on our first project using the RUP, hearing complaints from nearly all students over the lack of understandable examples, I bought Jacobsons's earlier book - Object Oriented Software Engineering. In that book I found much better and concrete examples, which were very helpfull in understanding their latest book (but that shouldn't be necessary!). If you are looking for an easy introduction to the unified process, conveniently having things explained for you in an easy to understand way, then this is definitely not the book for you. Very poor examples - or should I say lack of good and understandable examples. On the other hand, if you don't know so much about ooad, has lots of time, likes to crack nuts, read between the lines and guess about this and that, then this book is for you. - I admit that after having gone through the hard process, gaining experience in RUP through a practical project, I have come to like the process and has found it very usefull. The principles of the RUP are sound and good. Now that I have gone through the struggle, and knows it better, I'm glad that I have it on my shelf. It contains a lot of usefull, but unfortunately poorly explained, and illustrated, information.

Like many software developers with good ideas, the trio of Jacobson/Booch/Rumbaugh can't write to save their souls. There's good material in here if you can filter out the tedious repetitions, redundancies, and points of misplaced emphasis. The book completely fails to communicate the authors' important methodological insights. Sigh. I'm disappointed. But I'm keeping the book; it's good enough to stay in my library for a while.