Rating: 
Summary: Bone dry reference material
Review: 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.
Rating: 
Summary: Not well written
Review: This book could have been a very good book given the coverage of topics and general thrust. Unfortunately it is poorly written, as other reviews have pointed out. I used the book as a required text in a class of fifty college students and it was not popular. In the end I felt as if the book hurt the students' appreciation of good software methodology: it makes it seem like bureaucracy and nomenclature, not something important, challenging, and exciting.
Rating: 
Summary: The next step from the Unified Modelling Language
Review: 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).
Rating: 
Summary: The worst book I have ever had the displeasure of reading.
Review: 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!
Rating:
Summary: Must-have addition to your bookshelf...
Review: This book is a well-written concise overview of the software development process. It does not go into great depth in each area, but provides a well-chosen view into the different areas of software engineering. I really appreciate the diagrams, they communicate the essential ideas very well.
Rating:
Summary: A long-winded re-iteration of the obvious.
Review: 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.
Rating:
Summary: Boring and Obvious
Review: This book touches on some nice topics but if fails to state anything more then the obvious for anyone that knows anything about OO and the unified process.
I kept reading from one chapter to the next wondering where the actual detailed content was going to start but it never did.
On top of that it is written in such a boring way that I had trouble staying awake on numerous occasions.
Whether you're new to Computer Science or OO or have been in the industry for a while (as I have), you can do much better than this book.
Rating:
Summary: The definitive UML process book
Review: This book, the third in the Rational Amigos' UML trilogy, promises to become the definitive process book for applying UML to model large systems. It presents a comprehensive and rigorous description of a proven object-oriented software engineering process that can trace its lineage to Objectory. Through a series of engaging UML examples it effectively explains what it means to be "use-case driven, architecture-centric and iterative-incremental." This is the process book that I recommend to colleagues and clients when they ask me how to use UML to model enterprise systems
Rating:
Summary: A reasonable book on process but with limitations
Review: This is a book about process, not about RE or OOAD techniques. If you don't know how to do use case analysis, you will not find this book satisfying. I think that it does an adequate job at demonstrating what a that will fit any project and any organisation. The process shown here will fit a good number of green field projects, small and medium sized. When it comes to other situations (large projects, re-engineering, maintenance and customization) then this process must be adapted and possibly amended. The authors acknowledge this limitation and point to (one might say advertise) Rational's Objectory tool for process customisation. Whether that is the answer is questionable. For large projects I suggest a look at Scott Ambler's books 'Process Patterns' and 'More Process Patterns'. What the reader or anybody interested in process needs to understand is the fact that putting process into place requires 'process engineering' and ongoing process maintenance. This is unfortunately not stressed enough in the book, giving the impression of a 'silver bullet'. Process is not a silver bullet! Another issue I have with the process is its focus on use cases for everything. Use cases are useful but trying them to be the carrier of every operation results in abnormal constraints. For example I find the testing section to be inadequate for the simple reason that use case based testing is but one of a number of techniques an experienced tester has to employ. The book has a reasonable scope but its strength are in RE (requirements engineering), Analysis&Design and Construction phases. It turns weak when it comes to the periphery ie, project initiation, testing, Ambler's book as well. Don't let it lock you in and understand that there is more required than just giving the book to people.
Rating:
Summary: Beyond UML - The Shortcomings of Object Modeling
Review: Unfortunately, this is one of the poorest books I have ever read. To begin with, the langauge is stilted and difficult to follow. It is as if the authors wrote the book in a different language and then translated the work into English. If the purpose is to communicate concepts, the work falls short for this reason. The primary difficultly with the work lies in some of the assumptions of the unified process. First, analysis and the upper lifecycle of systems development are treated very cavalierly. The attitude is that analysis is okay and may yield some valuable information, but you should be able to go right into design without wasting all that time in analysis. My 11 years of professional experience indicates otherwise. The next difficultly is communication between various audiences. UML is touted as the most effective diagramming technique for communicating both business and software concepts. Yet the modeling techniques are severely lacking in techniques for capturing fundemental business information. In addition, many of the concepts presented are very esoteric and peculiar to object modeling and are not easily applied to the business world or even to transaction-based software applications. There is also a concerted effort to ignore many valuable techniques developed in such disciplines as Information Engineering, Structured Analysis and Design, etc. The UML will be a mature enough modeling language only after these missing pieces have been incorporated. If you want to familiarize yourself with the buzz words of the object community, buy the book. Otherwise, I wouldn't recommend wasting your money.
| 
