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: 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: Good introduction to RUP for beginners
Review: One thing's for sure: it's impossible for any one person to "know" the Rational Unified Process in and out. So, stop right there if you're looking to get the printed documentation of RUP, because it's logistically impossible to bundle it all into a paperback book. These titles give a bird's eye view of what RUP is and how it can be leveraged for optimal productivity in the vein of software development.
This book gives you great high-level insight on how your organization can benefit by adopting and implementing RUP in your developmental projects.
"The Rational Unified Process: An Introduction" is an overview into the theory behind RUP. Great chart and graphics describe the processes RUP is rooted in, and the title is written in such a way as to indirectly hammer home the concepts into your subconscious, without being too blatantly redundant. Essentially, you'll get the jist of RUP - iterations, that the waterfall process isn't efficient, the importance of establishing diversity in team-based development, and the importance of architecture.
Basically, the book also enforces the concept that self-organization and communication within an organization (within the team, throughout the company, and with clients) is key. It reads more like a business journal than a technical guide, so hands-on examples are left out.
Also, the poster summarizing the key RUP activities that's included with the book is really great. I would have liked a case study at the end of the book to tie together the concepts with a practical example, but the book is great otherwise. I also found the fact that samples of RUP templates to be a bit disappointing. A helpful appendix listing some (not all) of the key artifacts used in RUP planning is also appreciated.
Rating:
Summary: A good overview of the entire RUP framework...
Review: Target Audience
IT professionals who need to learn about the Rational Unified Process (RUP) Contents
This book is a relatively high-level overview of the entire RUP process. The book is divided into the following chapters: Software Development Best Practices; The Rational Unified Process; Static Structure: Process Description; Dynamic Structure: Iterative Development; An Architecture-Centric Process; A Use-Case-Driven Process; The Project Management Discipline; The Business Modeling Discipline; The Requirements Discipline; The Analysis and Design Discipline; The Implementation Discipline; The Test Discipline; The Configuration and Change Management Discipline; The Environment Discipline; The Deployment Discipline; Typical Iteration Plans; Implementing the Rational Unified Process; Summary of Roles; Summary of Artifacts; Acronyms; Glossary; Bibliography; Index Review
The Rational Unified Process, or RUP, is a software engineering methodology that attempts to map out and document all parts of a software development project. It's extremely comprehensive, but it's also adaptable to whatever level of effort is appropriate for your situation. This book, The Rational Unified Process - An Introduction, is a good start to begin your understanding of RUP. First off, let me say this is not an easy read. It's a good book with all the information you need to know to start using RUP, but the information is dense and highly detail oriented. Like most developers, I'm more oriented towards coding and testing. But realistically, you need to know what the system should do before you get to the coding piece. RUP helps to put all that into a formal framework so that the necessary things will get done in the proper order. While the entire RUP framework might feel overwhelming, the author makes sure to let you know that you can adapt the RUP to meet your situation. If you are adding a function to an existing system, you will be more focused on use cases, development, and deployment processes. The author does a good job in segmenting the information so that you can more easily focus on your needs. You should also not consider this the end-all volume on RUP that you will ever need. Kruchten doesn't try to detail specific techniques like use cases or UML. You will learn where they fit in to RUP, but you will need additional information on how to implement use cases or UML diagrams. Consider this the volume that allows you to place everything in a mental framework so that you can figure out what you will need to know going forward. Conclusion
If you are considering or in the process of implementing RUP, this is a book you should be studying. It's not an easy read, but it will give you the overview you need to understand the process and concepts.
Rating:
Summary: A good overview of the entire RUP framework...
Review: Target Audience
IT professionals who need to learn about the Rational Unified Process (RUP) Contents
This book is a relatively high-level overview of the entire RUP process. The book is divided into the following chapters: Software Development Best Practices; The Rational Unified Process; Static Structure: Process Description; Dynamic Structure: Iterative Development; An Architecture-Centric Process; A Use-Case-Driven Process; The Project Management Discipline; The Business Modeling Discipline; The Requirements Discipline; The Analysis and Design Discipline; The Implementation Discipline; The Test Discipline; The Configuration and Change Management Discipline; The Environment Discipline; The Deployment Discipline; Typical Iteration Plans; Implementing the Rational Unified Process; Summary of Roles; Summary of Artifacts; Acronyms; Glossary; Bibliography; Index Review
The Rational Unified Process, or RUP, is a software engineering methodology that attempts to map out and document all parts of a software development project. It's extremely comprehensive, but it's also adaptable to whatever level of effort is appropriate for your situation. This book, The Rational Unified Process - An Introduction, is a good start to begin your understanding of RUP. First off, let me say this is not an easy read. It's a good book with all the information you need to know to start using RUP, but the information is dense and highly detail oriented. Like most developers, I'm more oriented towards coding and testing. But realistically, you need to know what the system should do before you get to the coding piece. RUP helps to put all that into a formal framework so that the necessary things will get done in the proper order. While the entire RUP framework might feel overwhelming, the author makes sure to let you know that you can adapt the RUP to meet your situation. If you are adding a function to an existing system, you will be more focused on use cases, development, and deployment processes. The author does a good job in segmenting the information so that you can more easily focus on your needs. You should also not consider this the end-all volume on RUP that you will ever need. Kruchten doesn't try to detail specific techniques like use cases or UML. You will learn where they fit in to RUP, but you will need additional information on how to implement use cases or UML diagrams. Consider this the volume that allows you to place everything in a mental framework so that you can figure out what you will need to know going forward. Conclusion
If you are considering or in the process of implementing RUP, this is a book you should be studying. It's not an easy read, but it will give you the overview you need to understand the process and concepts.
Rating:
Summary: If you are interested in RUP, this is the place to start.
Review: The Rational Unified Process (RUP) was originally developed by Rational Software, which was recently purchased by IBM. Therefore, you now see the RUP sometimes referred to as IBM's Web-enabled software engineering process. As this name implies, it is a set of guidelines, some soft and others fairly rigid to the point of being a rule, for the creation of software. Like all useful principles of computer science, the RUP is a dynamic entity, being constantly modified to reflect the changes taking place in software creation. Therefore, if you are already familiar with the RUP and are wondering if you should read this book, the answer is an emphatic yes. If you are unfamiliar with the RUP, the answer is an even more emphatic yes.
The purpose of this book is to provide an introduction to RUP 2003, the latest iteration of the process. Like the previous books on RUP, it is written at a level suitable for managers. There is some necessary technical jargon, but nothing beyond what a software project development manager would be expected to be able to comprehend.
The book opens with a history of the RUP, what it is used for and the overall structure of the RUP. This is followed by a very brief introduction to fundamental concepts such as iterative development, architecture-centric processes and use cases. Necessary for beginners, most of this material can be skipped by those having experience in those areas.
Part II covers the various areas, referred to as disciplines. They are: * The project management discipline.
* The business-modeling discipline.
* The requirements discipline.
* The analysis and design discipline.
* The implementation discipline.
* The test discipline.
* The configuration and change management discipline.
* The environment discipline.
* The deployment discipline. While the steps used in the analysis differs from discipline to discipline, the following are common to all: * Purpose.
* Roles and artifacts.
* Workflow.
* Tool support.
* Summary. The tool support section is particularly helpful if you are evaluating the RUP for possible use in your organization. IBM/Rational has many tools that can aid you in your efficient use of the RUP. In fact, without software tools to aid you, much of the material in this book would be of theoretical interest only.
Large software projects require an overall organizing process to be imposed on them if there is to be a chance for successful completion. The RUP is currently one of the best such processes and this book will show the fundamentals of the process and how it can work for you.
Rating:
Summary: Not a book to teach you how to use RUP
Review: This book introduces the logic behind Rational Unified Process (RUP). RUP is a novel idea. It puts several good practices in a consolidated package. What makes RUP useful is the fact that Rational provides all the necessary software tools to support this. This book does an average job in explaining the RUP. It over stresses obvious and well accepted concepts like "iterative development"; which makes the first half (6 chapters) of this book a bit boring. For a professional with software development and management experience, I found the first sixe chapters are best read at a cursory glance. The second half of the book introduces the workflows - and it is this half that I found more interesting. I finished this book as bed time readoing over the weekend - so this book is an easy reading. However this book is not about teaching how to use Rational Products. This book only gives an overview of the basis of origination of RUP. You would need another book to become an expert in using RUP.
Rating:
Summary: Much better read than Unified Software Development Process
Review: This book is a much better read than the generic process described by the book named The Unified Software Development Process (UP). The Rational Unified Process (RUP) is a specific instance of the more generic UP. The RUP can be tailored to an organization or project and is considered a product offering by Rational Corp. Many big technology firms are using RUP to include major companies from Telecommunications, Transportation, Aerospace, Defense, Manufacturing, Financial Institutions, and System Integratrors. Some of the major well known companies include: Xerox, Intel, Oracle, Lockheed-Martin, Merrill Lynch, MCI and Charles Schwab. This book is easy to follow and very informative about a modern user-case driven, architecture centric, iterative/incremental development process. After an introduction to the whole process structure consisting of a Conception Phase, Elaboration Phase, Construction Phase and Transition Phase, each succeeding chapter covers a single workflow such as Business Modeling, Requirements Management, Analysis & Design, Implementation, Testing, Deployment, Configuration & Change Management, Project Management and Environment. This book is actually an enjoyable read and makes the reader aware of what it takes to develop software using an object-oriented software development process using a proven methodology.
Rating:
Summary: A fine, readable introduction
Review: This book is an introduction to the Rational Unified Process (RUP). It is suitable for readers who have never heard of RUP before and for readers who have little experience with thoughtful analysis of software lifecycles. (I think it's also very useful as a quick, easy-to-read overview of RUP for more advanced readers, but you can read about that use of the book in other reviews.) I teach Computer Science at Florida Tech, including undergraduate and graduate courses in software testing. Krutchen provides a thoughtful but very readable, persuasive discussion of risks associated with different software lifecycles. In my experience as a teacher, my students' ability to appreciate differences among lifecycles and analyze them critically is significantly boosted by study and discussion of Krutchen. Accordingly, I require my students to read the relevant section of his book, they have detailed small-group discussions of it, and it often appears on their exam. This book is an introduction. It doesn't address all of the problems with RUP. It doesn't cover all of the areas of RUP equally well. It won't make any reader an expert in the process or its favored practices. It won't persuade someone who doesn't like RUP that they should like. What it does do is expose the reader to the thinking and practices that make up this particular approach to software engineering. This book is much deeper than marketing fluff, but not so deep as to lose a junior reader. As a teacher, I am delighted to have materials like this available. (Disclosure: a little bit of my work has been included in RUP, and I have developed a course for Rational on software testing within the Rational process. However, I identify more with the agile development / XP community than with the RUP community. In any case, the question that I'm interested in answering in this review is not whether RUP is any good -- it has its good points and its weaknesses -- but rather whether Krutchen's introduction to RUP is a fair and useful introduction to that subject matter. My conclusion is that it is.)
| 
