I'm a mechatronics engineer with no formal training in software design. I bought this book to learn the basics of software design for a major project. I regret every penny I spent.



The book contains a nugget or two of useful information, but its writing could not have been worse. A sizable part of the book is dedicated to explaining why software engineers need a formal design process, why that process should be need- and risk-driven, and why it needs to be iterative. This information is very basic; ANYONE should be aware of it almost instinctively. But the book spends hundreds of pages on these basic facts. This is very patronizing and insulting to readers' intelligence. Furthermore, instead of being concise and precise, the book rambles and rambles and rambles and...



In summary, this is a very poorly written, rambling, patronizing, and useless book, not worth a penny. I am writing this evaluation out of extreme anger. When you spend $50+ and several days reading a 300-page book to learn NOTHING, you have the right to feel insulted by the authors. I know no more about software design now than I knew before reading the book.

I'm a mechatronics engineer with no formal training in software design. I bought this book to learn the basics of software design for a major project. I regret every penny I spent.

The book contains a nugget or two of useful information, but its writing could not have been worse. A sizable part of the book is dedicated to explaining why software engineers need a formal design process, why that process should be need- and risk-driven, and why it needs to be iterative. This information is very basic; ANYONE should be aware of it almost instinctively. But the book spends hundreds of pages on these basic facts. This is very patronizing and insulting to readers' intelligence. Furthermore, instead of being concise and precise, the book rambles and rambles and rambles and...

In summary, this is a very poorly written, rambling, patronizing, and useless book, not worth a penny. I am writing this evaluation out of extreme anger. When you spend $50+ and several days reading a 300-page book to learn NOTHING, you have the right to feel insulted by the authors. I know no more about software design now than I knew before reading the book.

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.

The "Unified Software Development Process" is still probably the best book yet on software process. Yes, it's difficult to read and it's not an introduction by any means (it reads like a textbook). but, if you're willing to put in the time and effort, what you'll get out of it is i think is worth it. I often had to go over a page many times to understand exactly what they saying, and routinely ended up with a headache. but, I really think it pays off.

The process they present just makes sense, and seems to be the right way to make software. The main ideas (iterative AND phased development, and architecture centric while being use case driven) blends the best from the software development world. I feel that on my successful projects, these same ideas just seem to intuitively happen.

Unlike most process books, this one goes into detail. It shows you what deliveribles you should be creating, what types of workers should be working on the deliverbles and when. These details, for me gave me a much, much clearer understanding about how a process should work. Things aren't so high-level. You can apply them (once you've figured them out) by just following the workflows.

To me, this book has as its foundation in one of Ivar Jacobson's previous software books: "Object-Oriented Software Engineering" (if you think his current book is hard to read, you should see this one, ugh). Also, an excellent book and should be read by every software architect.

I think if you read both these books, you'll have a very solid foundation for what you need to know about Software Engineering. A previous reviewer is right, this is not a introductory text. It's better to read an intro book on the rational unified process first before moving on to this one.

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.

If you want to be an archtiect or a lead programmer, read it and try to make sense of it. Otherwise, don't bother.

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.

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.

I have worked on OO since 1987 and have come to the conclusion that objects and use cases alone are not sufficient for success (I suspect that they may be necessary but that is another discussion). The UML and use cases are rooted in the object mindset. It is not possible to design and maintain large systems with objects and use cases. A use case is by definition an interaction session with an actor. What happens if there are very many actors, each one doing its own thing? The answer is anarchy.

What we need is a revision of the object paradigm. In particular, use cases are OK but before we discover them we must concentrate on viewpoints and requirements (UML 2.0 here we come).

The major weakness in Jacobson's book is the total lack of architecture. It is not true when the authors claim that use case drive architecture.

The Boundary-Entity-Control patterns is good but have the authors seen what is being done at CMU in the area of PAC (Presentation Abstraction Control) model?

Concluding, the example in the book is worn out by now (ATM). The UML has not kept abreast of new developments such as core process modelling, architecture and patterns. Many of my customers are beginning to reach the boundaris of UML and the RUP.

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

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.

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.

In my opinion, I think this book is quite good. One review which I perused through, which states that this book is only reiteration of the obvious, I do not quite agree.

The reasons are:

a) Some software engineers do not come from a background in which they are familiar with the usage of UML. It's one thing to know the notations of UML and quite another to apply it to designing of systems(I am going through that). Therefore, this book provides a comprehensive view on "how-to" apply UML to developing a software, hence termed "Unified Software Development Process". (Remember the time when one has to do analysis or design work when one begins to frequently ask many 'why's)

b) Reinteration has its good points as well. Reiteration of concepts, which you will find frequently in this book will enable the concepts to find their way into the membranes of the brain cells of reader sufficiently emough to burn holes. This is especially true for one who has just stepped into the arena of system analysing and designing. The conveying of the unified development concepts is so crystal clear that there are no holes by which reader has to assume. Everything is laid bare.

c) The reader would be in a strong position to understand nitty gritty of the process, for example, what Analysis is, what it entails, the differences between analysis and designs/implementation and the pros and cons.

Therefore, if you think you're a pro and extremely well versed(as in you know the ins and outs at a quick snap of finger) with the Unified Process just as Laotse was well versed and in touch with the nature, then you can forget this book. But if you want to be truly professional in this kind of work, this book is something you cannot do without.

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.

If all you want to do is to throw together a dog kennel, then avoid this book.

If you want to create a repeatable development process that is capable of continuous improvement, then look no further. The USDP stands the test of time.

The book deals with all aspects of a Software Construction Process in a frank, logical and full manner. It must be the seminal work on the subject.

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

I had to read this book for a Software System Design class. I put it down half way through the semester. This book was extremely wordy and all points were absolutely beaten to death. The authors could have adequately covered the material in half the number of pages they used. There must be a better book out there on this topic.

il est bien con�u et il convient bien � mettre en oeuvre UM

il est bien conçu et il convient bien à mettre en oeuvre UM

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!

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.

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.

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.

I think this book have influence of Brooks, If you read the Mythical Month Man you will recognize all in the sense that the guidance of software engineering are like the Brooks's book (it has over 25 years). Also go so far.But its not for UML or POO, its oriented to the Software Engineering good practice.Excellent for large projects.But too general. If you want a book of software engineering this is for you.

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.

The first reason for which I only gave 2 stars to this book is its weight. I'm sure that all this stuff can be given in at least the half size. To stay in drawbacks, we even have no effective guidelines for the activities, but only dry and "outside" description of activities. Moreover, the organisation with deeply nested sub-sections make the reading difficult. In the Unified Process itself, we had an interesting and detailled picture, with a lot of activities, workers and artifacts, but in fact it is a very classical approach (maybe it is a quality ?). But when the authors said that the method intagrates a component approach and patterns, it sound like a joke. I found painfull to read this book, because it's written in an unpleasant maneer, whatever the stuff inside. I hope to do not have to read such a dry book more than once per 5 year.

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.

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.

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

Most of us use a process to software development. Most of us do not use a formal process to do it. This book describes a formal process to software development. It is not the first book in its class nor is the last one. But it is one of the best I have ever read.

Ivar's describes the Unified Software Development Process from top to bottom (the workflows) and from minute 0 to project delivery (the phases) in great detail.

Be aware that this is not a object oriented analysis and design book. It is a software development process book.

He explains what is the role that every developer should have in every workflow (requirements, analysis, design, implementation) and also the list of deliverables in every phase.

The author explains in great detail what to look for (the goals) in every step on the software development. This is something that I have found really valuable.

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.

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.

Many organizations continue to look for silver bullets to answer the aliments of their software delivery capabilities. While this book is not the complete answer (as clearly recognized by the authors "A complete account of a comprehensive, full life-cycle process is beyond the scope of any one book."), it is a solid and useful description of the software development process. The Unified Software Development Process is a significant piece of work that can be used as the basis for standardization by any software agency. With the Unified Software Development Process's flexibility and inherent continuity as the general definition, a number of very specific and precise development cases can be created. The advantage in building these development cases under the Unified Software Development Process is the tractability and traceability of the artifacts, and thus the consistency required for increasing maturity of the software practices in an organization.

The authors have provided an enormous service to software agencies of large corporations by publishing this book to the public. However, the agencies themselves, through good process management and engineering practices, will need to provide the necessary extensions and integration to the practices of Project Management, Business Engineering and Governance to make this process directly applicable and capable of delivering true value. Nevertheless, as a person who dealt with this problem for many years in a large telecommunication company and now interacts with dozens of companies still wrestling with this problem, I strongly recommend this book.

The hard thing to understand is how this is any different than the Rational Unified Process documented in another book. My conclusion is that it isn't. This book is just longer.

It should be pointed out that this is not a neutral book as it is written by the co-owners of Rational Software and their process relays on using tools which they sell. However, on the positive side, at least, it doesn't beat this to death.

The book is unusual in that it has parts that are appropiate for developers as well as project managers. Both are handled equally well. Project manages will like the book because it describes the phases, iterations, and risk managements. Designers will like the technical step-by-step information.

The book is very easy to read and easy to understand. The sentence structure at times gets very repetitive, but actually that is the worst weakness of the book, which says a lot (that the explanations are not the core problem).

This book is a must read for any serious OO designer or project manager. Even if it wasn't a good book, which it is, it is going to be the default process used in many companies.

I've found Jacobson's book to be very useful. Athough not as fun to read as one of Booch's books, it nevertheless has great content.

Having recently started a project using the Unified Process, this book gave me all the details on what to do for each step. I've read about half the book, hitting the overview chapters, and the workflow chapters up through analysis, and having hit the phase chapters up through Inception, plus a few others, out of order.

I found the book to be a great guide in planning my iterations and deciding what activities to include or not include in my first iteration cycle.

As an engineer doing project management activities, I've found the Unified Process to give me a great structure from which to drive the engineering.

The only problem with the book for me, is that my team has decided to use the Rational Unified Process, and we've found Philippe Kruchten's book "The Rational Unified Process" and the Rational RUP product to be more convenient sources of distilled information, given our time pressure. But Jacobson's book is still the foundation of our plans, and is the only source of Analysis details, which Kruchen virually ignores.

In short, I'd recommend this book after you've read Kruchen's introductory book and want more details.

The arriving of UML has had a tremendous impact on the software world. With the speed of its acceptance UML has everyone talking in the same notation (if not the same language). This book takes the debate to the next logical level, which is the process of actually building complex software systems.

The Unified Process has the correct focus of building software for the users (requirements driven) in a given framework (architecture centric). It also emphasizes iterative development, which is a key success factor in today's market.

The book is well organized and extremely adept at tackling such a complex issue. By identifying artifacts, workers and workflow for every phase of software development, the book delivers actionable advice to project managers and software developers.

It is important to identify the book's focus and not confuse it with other topics, such as Business Process Reengineering and Object Reuse.

It is obvious that the Unified Process is a distillation of years of experience and should be a reference point for anyone who is trying to tackle software development

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.

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.

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.

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