The Rational Unified Process: An Introduction (2nd Edition) [Paperback]

Philippe Kruchten (Author)

Book Description

ISBN-10: 0201707101 | ISBN-13: 978-0201707106 | Publication Date: March 14, 2000 | Edition: 2

This book is the fastest way to get up- and-running with Rational Unified Process 2000 -- the industry's most powerful tool for incorporating best practices into software development. Authored by RUP's Lead Architect, it reflects all the major improvements made in the newest version of RUP, including its improved support for business engineering, management of non-functional requirements, and deployment of multi-tier distributed applications. Discover how RUP 2000 can enable development teams to maximize software quality -- within predictable schedules and reasonable budgets. Understand what RUP 2000 is, how it evolved, and how it fits into the development process. Next, review the structure of RUP 2000, mastering its use throughout the entire project lifecycle. This edition includes substantial new coverage of application interface design (including Web applications); patterns and frameworks; real-time and reactive systems; lifecycle testing, and more. There are new process roadmaps that demonstrate RUP 2000 at work with many projects and technologies; as well as expanded checklists and guidelines for process artifacts, activities, and phases.

Editorial Reviews

Review

The Rational Unified Process: An Introduction is a good overview of Rational's prescription for whole-project health. The process is unified as in "Unified Field Theory." Thesis, Antithesis, and Synthesis, (or Booch, Jacobson, and Rumbaugh, as they are known today) twine in a celestial dance to the Spheres, Rectangles, Clouds, and stray pointers that make up UML and its increasingly ambitious extensions, additions, and heroic leaps of faith.

Rational visualizes the elements and modalities of code and projects in a fashion found compelling by increasing numbers of corporate customers. It's a vision embodied in several software suites, including the eponymous Rational Unified Process, for which this book is designed to serve as the introduction. Face it, you are going to run into Rational on the job. This volume is a good place to get know about it.

The book is not an independent assessment of Rational. Editor Philippe Kruchten is lead architect of the Rational Unified Process product. The thrust is the process of processes, specifically process in software projects, as viewed by Rational and supported by its project-management toolsets. Read more--Jack Woehr, Dr. Dobb's Journal -- Dr. Dobb's Journal --This text refers to the Textbook Binding edition.

From the Back Cover

Philippe Kruchten is the lead architect of the Rational Unified Process. Mr. Kruchten has more than twenty-seven years of experience in the development of large, software-intensive systems for telecommunications, defense, aerospace, transportation, and software development tools. He is also the author of The Rational Unified Process, An Introduction (Addison-Wesley), which has been translated into seven languages and has sold more than 150,000 copies in its two editions.

0201707101AB03062003

See all Editorial Reviews

Product Details

• Paperback: 320 pages
• Publisher: Addison-Wesley Professional; 2 edition (March 14, 2000)
• Language: English
• ISBN-10: 0201707101
• ISBN-13: 978-0201707106
• Product Dimensions: 8.9 x 6.9 x 0.5 inches
• Shipping Weight: 15.7 ounces
• Average Customer Review: 3.9 out of 5 stars  See all reviews (36 customer reviews)
• Amazon Best Sellers Rank: #1,806,688 in Books (See Top 100 in Books)

More About the Author

Philippe Kruchten is a professor of software engineering at the University of British Columbia, in Vancouver, Canada, after retiring from 30+ years in industry in various countries around the globe. His current interests are software process modeling, agile processes, and software architecture, and the impact of culture on global software engineering projects. Prior to UBC, he spent 16 years at Rational Software (now IBM Software Group), where he was associated as a consultant with several large-scale defense and aerospace projects around the world, and where he developed the Rational Unified Process', a software engineering handbook used by half a million developers around the world. He also spent 8 years at Alcatel in France, developing telephone switches. He has a mechanical engineering diploma and a doctorate degree in computer science from French institutions. Dr. Kruchten is a professional software engineer, and councilor at APEGBC.

Customer Reviews

Most Helpful Customer Reviews

50 of 51 people found the following review helpful:

4.0 out of 5 stars Worth readng even if you don't buy the product, February 9, 2001

By 

Charles Ashbacher (Marion, Iowa United States) - See all my reviews
(TOP 500 REVIEWER)    (VINE VOICE)    (HALL OF FAME REVIEWER)   

This review is from: The Rational Unified Process: An Introduction (2nd Edition) (Paperback)

There are those who might criticize this book as being a mere commercial for the development tools offered by Rational Software. My reaction to that position is, `so what." If I am a manager considering the adoption of the Rational Unified Process, then my best hope for making the correct adoption decision is to learn what it is designed to do in as short a time as possible. Any material that I can read at a managerial level that explains the capability and what I can get out of it is something of great value, and this book satisfies that requirement.
The main purpose of the book is to explain the unified process at the level of the tops of the trees. This broad overview is an explanation of how a process is constructed by splitting it up into nine overlapping, but still somewhat distinct workflows. They are the project management workflow, the business modeling workflow, the requirements workflow, the analysis and design workflow, the implementation workflow, the test workflow, the configuration and change workflow, the environment workflow and the deployment workflow. The separation of the process into the different sections allows each of them to be described from their somewhat unique perspectives, which makes it easier to see how the synergy of them all makes for a complete, effective process.
It took some time for it to appear, but it is now essential to examine an item of software from the architectural perspective. Such an encompassing examination of software could not exist until the projects grew to such size and complexity that no other paradigm could adequately describe it. Like the plans for a large, complicated building, it is the overlap of several different models that merge together to build something that is more than the collection of pieces. An entire chapter is devoted to the importance of the architecture in the development and unending refinement of a software project. These are wise words to heed, as anyone who tries to build the complex without a sound plan is almost certainly doomed to failure.
The most significant test that any book describing a product can face is whether it is still worth reading if you have no interest in the product. This book easily passes that test and is one of the best manuals for managers of large software projects that is available today.

31 of 31 people found the following review helpful:

5.0 out of 5 stars A fine, readable introduction, October 4, 2002

By 

Cem Kaner, J.D, Ph.D. (Palm Bay, FL United States) - See all my reviews

Amazon Verified Purchase

This review is from: The Rational Unified Process: An Introduction (2nd Edition) (Paperback)

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

31 of 31 people found the following review helpful:

4.0 out of 5 stars A fine book despite some reservations, January 27, 2002

By 

Vince Kenyon (Chicago, IL USA) - See all my reviews
(REAL NAME)   

This review is from: The Rational Unified Process: An Introduction (2nd Edition) (Paperback)

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.