Rating: 
Summary: The best book by the best authors on the Unified Process
Review: "The Unified Software Development Process" is the best comprehensive book written on the Unified Process. Known as the three amigos, Ivar Jacobson, James Rumbaugh, and Grady Booch are without a doubt the best leading experts on the UML and the Unified Process since they were the primary developers of the UML and tailored their combined development processes into the Unified Process, which makes the best use of applying and using the UML for specifying system blueprints for software intensive systems. The Unified Process is appropriate for using the UML for modeling because it uses a use case driven, architecture centric, iterative/incremental life cycle that complements the main features of the UML. If you want to learn UML, the best book to buy is "The Unified Modeling Language Users' Guide" by the three amigos. If you want to learn a modern day software development process that makes the best use of the industry standard specifications language, UML, then buy the "Unified Software Development Process", also written by the three amigos.
Rating:
Summary: The best book by the best authors on the Unified Process
Review: "The Unified Software Development Process" is the best comprehensive book written on the Unified Process. Known as the three amigos, Ivar Jacobson, James Rumbaugh, and Grady Booch are without a doubt the best leading experts on the UML and the Unified Process since they were the primary developers of the UML and tailored their combined development processes into the Unified Process, which makes the best use of applying and using the UML for specifying system blueprints for software intensive systems. The Unified Process is appropriate for using the UML for modeling because it uses a use case driven, architecture centric, iterative/incremental life cycle that complements the main features of the UML. If you want to learn UML, the best book to buy is "The Unified Modeling Language Users' Guide" by the three amigos. If you want to learn a modern day software development process that makes the best use of the industry standard specifications language, UML, then buy the "Unified Software Development Process", also written by the three amigos.
Rating: 
Summary: I can't believe I actually finished it
Review: 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.
Rating:
Summary: excellent if you understand some caveats
Review: An excellent book, it will without doubt make any given reader a better software engineer. However, the writing drones a bit. I sometimes spend too much time parsing sentences. This is in contrast to the Craig Larman offering, which is an easier read. On the positive side it's organization is excellent. The material is similar to Larman's book, and though Larman is a better writer (IMHO) the overall organization in this book enhances understanding to the point that I recommend this one over the Larman offering.
Rating:
Summary: The primary book for understanding SW development of today.
Review: Everyone today involved in software development ought to be aware of the contents of this book. The book is an overview of the key concepts, the core workflows and the overall management and control of software development. It's a comprehensive text-book, but it's not (and should not be) a detailed procedure manual for a software development process. In other words, it's a "conceptual and analysis model" of the software development business. But remember, it's not (and should not be) an applied design and implementation of a specific software development business. The three major parts of the Unified Process book are well balanced. The first part describes the key concepts: use-case driven, architecture-centric, and iterative and incremental. The second part goes deeper into the core workflows: requirements, analysis, design, implementation and test. Thus, this part is focusing on work to be done to produce a certain type of artifact. The third part describes how to manage and control this work in time space. This is based on the good principles for controlled iterative development and it is the most valuable part of the book. Like all good "conceptual and analysis models" this book assembles and unifies experience and best practices of the domain in focus; in this case software development. The result is a common "language" for the domain and a common approach of solving problems in the domain. Examples are included and provides a good complement to the more general text. Every chapter also contains a valuable list of references to other books and papers. For the ones that practice software development, the referenced book "The Unified Modeling Language User Guide" is a mandatory complement. If you are involved in business modeling, the referenced book "The Object Advantage - Business Process Reengineering with Object Technology" is a must. For the ones dealing with development of application families/suites, the referenced book "Software Reuse: Architecture, Process and Organization for Business Success" provides complementory guidance. In the next iteration of unifying software development processes and the next release of this book, I not only want to see references to the books about Business Processes and Software Reuse, but some elaboration and description of "the big picture". The interesting thing is that fundaments and the overall process pattern described in Unified Process (Objectory--RUP) can be applied on different "system" levels recursively. The same pattern can be used to reach different development targets, but depending on the type of target (a business, a system family, a component system, an application system, a subsystem, etc.), the development workflows, workers and artifacts need specialization. That's known by the authors, but it's cluttered and not distinctly described in the book. (The two referenced books would also benefit from being updated to harmonize with the corresponding versions of UML and Unified Process.) I would also like to comment on three other issues that could have been more elaborated: usability engineering to produce "partial business models", modeling of large systems as recursively superordinate/subordinate systems, and code generation. Business modeleing is not directly described, but is discussed in the chapter about Requirements Capture. It would have been interesting to address the possibility to only develop a partial business model, which doesn't fully model the whole business and its use cases, but directly identifies some workers (and maybe some business actors) and describe their "profile and tasks". This is what usually is done when usability engineering is applied. Maybe it's to hard to model and optionally change the whole business, but individual tasks might benefit from better information system support. That could sometimes be good enough. In order to find the (system) use cases it's better to apply usability engineering techniques, like user profiling and task analysis, then not doing any model at all of the business workers/actors. In order to handle complexities of large systems you need techniques to recursively model a number of system levels. This is just very briefly described in the book. An extract from the Software Reuse book about modeling of superordinate and subordinate systems wouldn't do any harm in the next release of the Unified Process book. Code generation is something that must be taken into consideration by software architects. This should have been discussed in the chapters addressing architecture, design and tools. To summarize, the Unified Process book is the primary book for understanding software development of today. I hope it will be a "living book" that is periodically updated to reflect the best practices of software development at each point of time in the future.
Rating: 
Summary: Best, most complete overview of the unified process.,
Review: For those looking for a comprehensive model for a disciplined software development process, this book is it. In this latest in the series of volumes from the Rational troika, Ivar Jacobson assumes the lead and takes us on a grand tour of the Unified Process. The book is a historical turning point. Far and away the best on the subject, it fills in many of the details missing from the earlier overview volume by Philippe Kruchten. For those familiar with the original object-oriented software engineering process developed by Jacobson at Ericsson and popularized under the Objectory rubric, the ancestry will be apparent, but the Unified Process has been elaborated through experience and the integration of other perspectives into a more comprehensive and universal model. If the undertaking were to be faulted at all, it would be in the ambitiousness of its premise, and only time and more experience will determine how close to a truly unified approach the authors have come. Although it is at times difficult to get a real overall picture of how all the various models and activities in the process fit together; the information is all there in the book. I commend this well-written and readable book to all managers and serious professionals who want a deeper understanding of how the sundry steps that lead to good software can be organized into a highly disciplined and manageable process.
Rating: 
Summary: This is not about the software development process.
Review: For three people as highly respected as Messrs. Jacobson, Booch, and Rumbaugh to have produced a book is so completely NOT about a software development process is a travesty. These gentlemen know about designing systems in an object-oriented environment. They seem to know nothing about obtaining and defining requirements for such a system. They begin with the "use case". This is not an attempt to determine what kinds of automation are appropriate for a given business function. It does not ask the question, "Should this process continue to be done in a newly automated world?" It presumes the process and presumes a systems whose basic shape and technology were already determined by the analyst before he began. It then simply addresses the question of what the user interface would look like. The appropriate place to start requirements analysis is with determination of the basic functions of the business, followed by determination of the extent to which current activities contribute to those functions. Many of the current activities only exist because of shortcomings in current systems. These should not be automated at all. They should be eliminated. After extensively discussing use cases, the three gentlemen then proceed to wave their hands over analysis, briefly describing "analysis artifacts" as being "more abstract" than design artifacts, but never really coming to grips with what such artifacts are supposed to do. Requirements analysis is the process of coming to grips with the fundamental processes, data structures and business rules of the organization. What is the nature of the company? How does it work? What is the true, fundamental, structure of its data? These are hard questions, and many books have been written on how to ask them. Unfortunately, this isn't one of those books. Mr. Rumbaugh, in his previous book, did a better job of addressing what is to happen during requirements analysis. It's a pity that he didn't bring more of that work forward into this book. We've heard a lot about "object-oriented analysis" lately. Unfortunately, not only does the "object-oriented" qualifier not mean a great leap forward in the way we do analysis - it means a leap backward.
Rating:
Summary: Terrible!
Review: I found this book utterly useless. The authors need to learn that every sentence in their book does not need to contain at least three industry buzzwords. It is next to impossible to read, and seems to only reiterate itself over and over again. If you are looking to learn more about UML, don't look for it here.
Rating: 
Summary: Non-habit forming sleep aid
Review: I had to buy this book for coursework. Now, I can't imagine authors with more knowledge of UML, etc. than these three guys. However, every chapter reads like a student paper in which the main intention is filling up space for credit. Don't get me wrong here. I read programming books for fun. I'm not one of those people who doesn't enjoy reading technical material. They just managed to take an already dry subject and dry it further. As you read through there are various references to other books, articles, whatever. It seems as though no original material was written for this book. So, here's my advice. Read those books. Don't read this one unless you need to catch up on some sleep.
Rating:
Summary: Non-habit forming sleep aid
Review: I had to buy this book for coursework. Now, I can't imagine authors with more knowledge of UML, etc. than these three guys. However, every chapter reads like a student paper in which the main intention is filling up space for credit. Don't get me wrong here. I read programming books for fun. I'm not one of those people who doesn't enjoy reading technical material. They just managed to take an already dry subject and dry it further. As you read through there are various references to other books, articles, whatever. It seems as though no original material was written for this book. So, here's my advice. Read those books. Don't read this one unless you need to catch up on some sleep.
| 
