Rating: 
Summary: A fine book despite some reservations
Review: An excellent book well organized and generally well written. Recommended either to learn about Rational Corporation's Rational Unified Process (RUP) or even just to get a general acquaintance with current ideas about software development methodology.Mr. Kruchten advocates describing a software product with various summary, abstract views. In this book, he practices what he preaches by giving just the "architectural" view of RUP, whose in-depth treatment would not fit in just 300 pages. There are seventeen chapters divided into two sections. A reader interested only in RUP's distinctive features may skip chapters 1 and 14-17. Section I comprising chapters 1-6 provides the motivation (software development best practices) and the dominant themes (architecture and use cases) of RUP, describing it also along two main dimensions: the dynamic dimension of phase and iteration and the static dimension of workflow. Section II dedicates a chapter to each of RUP's nine workflows. There are two final chapters, one with sample plans for iterations in different project phases and one discussing how to implement RUP in a development organization. There are two useful appendices, a dictionary of acronyms, a glossary, and a quite helpful annotated bibliography. In RUP a workflow is an interrelated set of activities producing a cohesive subset of the artifacts of a software development project. The chapters describing workflows vary somewhat in length and quality, but they all follow the same pattern: (1) start with guiding principles; (2) describe the activities, workers, and artifacts of the workflow; (3) conclude with some comments on tool support (a little marketing for Rational Corporation's tool suite). The best workflow chapters: Project Management, Business Modeling, Test, Configuration and Change Management. The high recommendation comes not without some reservations. Architectures are important in RUP, but Chapter 5, "An Architecture-centric Process," garbles this message by describing architectures as mere derivatives of "complete" system descriptions (called "models"): "Architecture is what remains when you cannot take away any more things and still understand the system and explain how it works (p. 82)." Again, " . . . models are complete representations of the system, whereas an architectural view focuses only on what is architecturally significant (p. 89)." Finally, "Architectural views are like slices cut through the various models, illuminating only the important, significant elements . . . (p. 90)." These explanations fail to recognize that architectures come first. Architectures are constraints that determine subsequent design and construction of the system. They are primary, not derivative, not mere views of models. Fortunately, RUP recognizes the primacy of architecture even if these explanations do not. These explanations also fail to recognize that an architecture is a complete and distinct model in its own right. They are out of harmony with the book's own (wordy) definition of architecture, which includes "The selection of structural elements and their interfaces by which the system is composed . . . (p. 84)." So when the elements and interfaces have been defined, the architecture is complete, right? It escapes this reader how architectures can be inherently less complete than models (whatever they are), when there is not even any one model that completely describes a system (see p. 81). The relationship that Chapter 5 describes between architectures and models is very similar to that described in Chapter 10 between the analysis model and the design model. Mr. Kruchten limits the value of retaining the analysis model as a distinct artifact: "Generally, there is one design model . . .. The upper layers of this model describe the application-specific, or more analysis-oriented, aspects . . . In some companies-those in which systems live for decades or there are many variants of the system-a separate analysis model has proved useful (p. 175)." Generally, companies that plan to stay in business DO expect their systems to live for decades-as do companies that spend millions of dollars using RUP to build them. As for "the extra work required to ensure that the analysis and design models remain consistent (p. 175)," the right tool can make all the difference. Anyone familiar with tools for database design (Erwin, for example) knows that they provide extensive facilities for maintaining separate, consistent analysis (logical) and design (physical) models. The tools offered by Rational Corporation, however, do NOT provide such a facility. Could Mr. Kruchten be tailoring the methodology to fit the limitations of the tool that his sponsor sells? Compare his attitude toward the analysis model with that of another author in the Addison-Wesley Object Technology Series. Martin Fowler in his UML Distilled says, " . . . it is very important to separate the specification perspective and the implementation perspective (p. 52)." Mr. Fowler uses different terminology, but he is saying essentially that the analysis model ("specification perspective") is valuable as an artifact distinct from the design model ("implementation perspective"). Despite these issues-which might profitably have been discussed at greater length-this fine book admirably fulfills its purpose.
Rating:
Summary: A fine book despite some reservations
Review: An excellent book well organized and generally well written. Recommended either to learn about Rational Corporation's Rational Unified Process (RUP) or even just to get a general acquaintance with current ideas about software development methodology. Mr. Kruchten advocates describing a software product with various summary, abstract views. In this book, he practices what he preaches by giving just the "architectural" view of RUP, whose in-depth treatment would not fit in just 300 pages. There are seventeen chapters divided into two sections. A reader interested only in RUP's distinctive features may skip chapters 1 and 14-17. Section I comprising chapters 1-6 provides the motivation (software development best practices) and the dominant themes (architecture and use cases) of RUP, describing it also along two main dimensions: the dynamic dimension of phase and iteration and the static dimension of workflow. Section II dedicates a chapter to each of RUP's nine workflows. There are two final chapters, one with sample plans for iterations in different project phases and one discussing how to implement RUP in a development organization. There are two useful appendices, a dictionary of acronyms, a glossary, and a quite helpful annotated bibliography. In RUP a workflow is an interrelated set of activities producing a cohesive subset of the artifacts of a software development project. The chapters describing workflows vary somewhat in length and quality, but they all follow the same pattern: (1) start with guiding principles; (2) describe the activities, workers, and artifacts of the workflow; (3) conclude with some comments on tool support (a little marketing for Rational Corporation's tool suite). The best workflow chapters: Project Management, Business Modeling, Test, Configuration and Change Management. The high recommendation comes not without some reservations. Architectures are important in RUP, but Chapter 5, "An Architecture-centric Process," garbles this message by describing architectures as mere derivatives of "complete" system descriptions (called "models"): "Architecture is what remains when you cannot take away any more things and still understand the system and explain how it works (p. 82)." Again, " . . . models are complete representations of the system, whereas an architectural view focuses only on what is architecturally significant (p. 89)." Finally, "Architectural views are like slices cut through the various models, illuminating only the important, significant elements . . . (p. 90)." These explanations fail to recognize that architectures come first. Architectures are constraints that determine subsequent design and construction of the system. They are primary, not derivative, not mere views of models. Fortunately, RUP recognizes the primacy of architecture even if these explanations do not. These explanations also fail to recognize that an architecture is a complete and distinct model in its own right. They are out of harmony with the book's own (wordy) definition of architecture, which includes "The selection of structural elements and their interfaces by which the system is composed . . . (p. 84)." So when the elements and interfaces have been defined, the architecture is complete, right? It escapes this reader how architectures can be inherently less complete than models (whatever they are), when there is not even any one model that completely describes a system (see p. 81). The relationship that Chapter 5 describes between architectures and models is very similar to that described in Chapter 10 between the analysis model and the design model. Mr. Kruchten limits the value of retaining the analysis model as a distinct artifact: "Generally, there is one design model . . .. The upper layers of this model describe the application-specific, or more analysis-oriented, aspects . . . In some companies-those in which systems live for decades or there are many variants of the system-a separate analysis model has proved useful (p. 175)." Generally, companies that plan to stay in business DO expect their systems to live for decades-as do companies that spend millions of dollars using RUP to build them. As for "the extra work required to ensure that the analysis and design models remain consistent (p. 175)," the right tool can make all the difference. Anyone familiar with tools for database design (Erwin, for example) knows that they provide extensive facilities for maintaining separate, consistent analysis (logical) and design (physical) models. The tools offered by Rational Corporation, however, do NOT provide such a facility. Could Mr. Kruchten be tailoring the methodology to fit the limitations of the tool that his sponsor sells? Compare his attitude toward the analysis model with that of another author in the Addison-Wesley Object Technology Series. Martin Fowler in his UML Distilled says, " . . . it is very important to separate the specification perspective and the implementation perspective (p. 52)." Mr. Fowler uses different terminology, but he is saying essentially that the analysis model ("specification perspective") is valuable as an artifact distinct from the design model ("implementation perspective"). Despite these issues-which might profitably have been discussed at greater length-this fine book admirably fulfills its purpose.
Rating: 
Summary: Get your project off of level 1.
Review: Excellent. A flexible framework for organizing all the things that make for a successful project. Very clearly written; proper level of detail.
Rating:
Summary: Definitive
Review: First of all, please let me clarify something. In another review of mine (for the book "The Rational Unified Process Made Easy" of Kroll & Kruchten) I mentioned that there are 3 books on the RUP. Well, this might have been true in August of 2003, but it is not anymore: There are 3 more books on the RUP out there, namely:
- "Adopting the Rational Unified Process"
- "Software Development for Small Teams"
- "Practical Software Engineering" (.NET-oriented) To be frank, I found the "Made Easy" book to a be a bit more fun than this one. Probably, because this book is more descriptive, whereas the "Made Easy" one is more normative. Having said that, I feel this book is the definitive book to have if you
are working with the RUP, and a heck of a useful book to read even if you're not. Especially now that everything Rational has gained more leverage (because of the acquisition of Rational Software by IBM that gives RUP an arguably more powerful marketing mechanism and exposure, let alone its plausible gradual integration into the methodologies used by the 150,000-people-strong IBM Global Services organization), this book becomes even more relevant. There is a foreword by Grady Booch (one of the 3 amigos) that goes though a can-never-remember-how-many thousand mile view of the whole landscape, followed by a chapter by the author, who briefly goes through all the nice concepts (iterative development, architecture, etc.) that permeate the RUP. There is also a brief history of the RUP in this chapter that I found quite illuminating. I always like to know the historal context; it usually helps explain the rationale behind ideas and constructs. The next chapter, entitled "Static Structure", discusses the constituent concepts of the RUP, namely role, activity, artifact, workflow, discipline, deliberately ignoring for the moment the temporal dimension (for the most part). It is chapter 4, "Dynamic Structure", where the core concept of iterative development is expounded, and the expected contrast with the traditional waterfall is made (hence explaining the rationale for coming up with the perhaps-not-intuitive-at-first-glance idea of iterative development). Phases and milestones are explained. If there are three pillars of the RUP, these are (i) iterative development, (ii) executable architecture, and (iii) use-case driven development. Hence, it comes to no surprise that the next two chapters deal with architecture and use cases. In chapter 5 a mention is made, among other things, to the author's important work on the 4+1 Views of Architecture that underlies the RUP. Chapter 6 is a condensed discussion of the role and merit of use cases in a software development process in general, and RUP in particular. This concludes Part I of the book. Part II consists of 9 chapters, one for each RUP so-called discipline (Project Management, Business Modeling, Requirements, Analysis and Design, Implementation, Test, Configuration, Environment, Deployment). The "Made Easy" book follows a similar pattern, with the difference, congruent with I've already mentioned above, that this book tends to treat the Disciplines in a descriptive rather than normative manner. There is a pretty good "Summary of Roles" appendix at the end, and I liked the Glossary too, as the definitions contained therein are very precise but at the same time very comprehensible too. Finally, there is a rich annotated bibliography section, which, if you're at all like me, you'll find rather useful (There's also a poster of the RUP at the back if you're into that sort of thing). All in all, I haven't at all regretted the €38.50 and the time I've spent reading the book; and imagine that I was familiar with this stuff already. If this happens to be the first book you read on RUP (as it should normally be) then the benefit for you will be even greater.
Rating:
Summary: bravo!
Review: Good and profoun
Rating:
Summary: good
Review: good boo
Rating: 
Summary: Good introduction/sales pitch to RUP
Review: Having heard about the Rational Unified Process (RUP) and having seen diagrams that depict the process with all the funny terminology, I wanted to find out more without wasting too much time. This book delivered my wish. After reading just this book on the RUP you will have no better or worst understanding of UML (as it does not touch the subject) and you will not be able to apply a process to a real project (more reading elsewhere is required for that). Having said that, an understanding of the process and its terminology along with whether it would be applicable to your projects will be formed. If you are looking for a 'helicopter' view on the RUP and nothing more, read this book. END
Rating:
Summary: Extended product pitch too light on examples to use
Review: I agree completely with the last reviewer. The book is just a teaser for the product (another 700 USD). Very disappointing after waiting for it for so long.
Rating:
Summary: Helps make the complex manageable!
Review: I am very impressed by the Rational Unified Process. This book does a great job of teaching you how to take the complex process of developing software and making it manageable. While I have been a part of complex projects before and have worked in an ISO 9001 environment for more than a year, I joined my first software development project that is making use of RUP recently. I am very impressed that this is "best practices." The book is well organized, easy to read, and very educational. Only a very few times is anything not extremely clear and accessible to even a newcomer to development such as myself. I would recommend this book be read by all members of a development team to assist in getting everyone speaking the same language and making full use of resources.
Rating:
Summary: How to understand RUP in little time
Review: I give 4 stars to this book, because it can be red in a very little time (a week-end, if you are motivated), otherwise I probably gave it only 3 stars. It is really an introduction, with swallow description of activities, but with an enought sufficient visibility on overall picture. The unpleasant part is the continuous recall of Rational Softwares, Showing all rational Software as pieces that perfectly fits together, which is not true. I think that a far from free book like that should be written without these continuous references.
| 
