Home > Store

Rational Unified Process Made Easy, The: A Practitioner's Guide to the RUP: A Practitioner's Guide to the RUP

Register your product to gain access to bonus material or receive a coupon.

Rational Unified Process Made Easy, The: A Practitioner's Guide to the RUP: A Practitioner's Guide to the RUP

Best Value Purchase

Book + eBook Bundle

  • Your Price: $63.39
  • List Price: $103.98
  • Includes EPUB, MOBI, and PDF
  • About eBook Formats
  • This eBook includes the following formats, accessible from your Account page after purchase:

    ePub EPUB The open industry format known for its reflowable content and usability on supported mobile devices.

    MOBI MOBI The eBook format compatible with the Amazon Kindle and Amazon Kindle applications.

    Adobe Reader PDF The popular standard, used most often with the free Adobe® Reader® software.

    This eBook requires no passwords or activation to read. We customize your eBook by discreetly watermarking it with your name, making it uniquely yours.

More Purchase Options


  • Your Price: $47.99
  • List Price: $59.99
  • Usually ships in 24 hours.

eBook (Watermarked)

  • Your Price: $35.19
  • List Price: $43.99
  • Includes EPUB, MOBI, and PDF
  • About eBook Formats
  • This eBook includes the following formats, accessible from your Account page after purchase:

    ePub EPUB The open industry format known for its reflowable content and usability on supported mobile devices.

    MOBI MOBI The eBook format compatible with the Amazon Kindle and Amazon Kindle applications.

    Adobe Reader PDF The popular standard, used most often with the free Adobe® Reader® software.

    This eBook requires no passwords or activation to read. We customize your eBook by discreetly watermarking it with your name, making it uniquely yours.



Explains the underlying software development principles behind the RUP, and guides reader in the application of it in their organization.

° Step-by-step instruction shows you how simple it can be to succeed with the RUP

° Shows how to incrementally adopt the RUP with minimal risk, and how to identify traps and pitfalls along the way.

° Authored by the foremost RUP experts in the field, backed up by examples of companies that have made the process work for them


  • Copyright 2003
  • Dimensions: 7" x 9"
  • Pages: 464
  • Edition: 1st
  • Book
  • ISBN-10: 0-321-16609-4
  • ISBN-13: 978-0-321-16609-8

"Per Kroll and Philippe Kruchten are especially well suited to explain the RUP...because they have been the central forces inside Rational Software behind the creation of the RUP and its delivery to projects around the world."

--From the Foreword by Grady Booch

This book is a comprehensive guide to modern software development practices, as embodied in the Rational Unified Process, or RUP. With the help of this book's practical advice and insight, software practitioners will learn how to tackle challenging development projects--small and large--using an iterative and risk-driven development approach with a proven track record.

The Rational Unified Process Made Easy will teach you the key points involved in planning and managing iterative projects, the fundamentals of component design and software architecture, and the proper employment of use cases. All team members--from project managers to analysts, from developers to testers--will learn how to immediately apply the RUP to their work. You will learn that the RUP is a flexible, versatile process framework that can be tailored to suit the needs of development projects of all types and sizes.

Key topics covered include:

  • How to use the RUP to develop iteratively, adopt an architecture-centric approach, mitigate risk, and verify software quality
  • Tasks associated with the four phases of the RUP: Inception, Elaboration, Construction, and Transition
  • Roles and responsibilities of project managers, architects, analysts, developers, testers, and process engineers in a RUP project
  • Incrementally adopting the RUP with minimal risk
  • Common patterns for failure with the RUP--and how to avoid them

Use this book to get quickly up to speed with the RUP, so you can easily employ the significant power of this process to increase the productivity of your team.


Related Article

Strategic Reuse Management and the Rational Unified Process (RUP)

Author's Site

Click below for Web Resources related to this title:
Author's Web Site

Sample Content

Downloadable Sample Chapter

Click below for Sample Chapter(s) related to this title:
Sample Chapter 1

Table of Contents






1. Introducing the Rational Unified Process.

What Is the Rational Unified Process?

The RUP—The Approach.

Underlying Principles of the RUP Approach.

The RUP and Iterative Development.

The RUP--A Well-Defined Software Engineering Process.

The Dynamic Structure of the Rational Unified Process.

The Static Structure of the Rational Unified Process.

The RUP-A Customizable Process Product.

Configuration and Process Authoring Tools.

Process Delivery Tools.

Who Uses the RUP Product?


2. The Spirit of the RUP: Guidelines for Success.

Attack Major Risks Early and Continuously, or They Will Attack You.


Ensure That You Deliver Value to Your Customer.


Stay Focused on Executable Software.


Accommodate Change Early in the Project.


Baseline an Executable Architecture Early On.


Build Your System with Components.


Work Together as One Team.


Make Quality a Way of Life, Not an Afterthought.



3. Comparing Processes: The RUP, Agile Methods, and Heavyweight Government Standards.

How Can We Compare Processes?

Agile Development: Low-Ceremony, Iterative Approaches.

SEI CMM, SEI CMMI, ISO/IEC, DOD-STD, MIL-STD: High Ceremony Striving for Higher Predictability.

SEI CMM: Process Assessment Framework.

SEI CMMI: Process Assessment Framework.

ISO/IEC 15504: Process Assessment Framework.

DOD-STD and MIL-STD: High-Ceremony Processes.

The RUP: An Iterative Approach with an Adaptable Level of Ceremony.

How Iterative Do You Want to Be?

How Much Ceremony Do You Want?

What Kind of RUP Configuration Meets Your Process Needs?

Project Deimos: Team of One.

Project Ganymede: Small Project with Tight Timeline.

Project Mars: Average-Size Project without Iterative Development Experience.

Project Jupiter: Large Distributed Project.


4. The RUP for a Team of One: Project Deimos.

A Solo Software Project: Project Deimos.

The Seminal Idea (Saturday Night).

The Proposal (Monday Morning).

The Vision.

The Plan.

The Risk List.

The Business Case.

The Architecture.

The Commitment (Monday Lunch).

The Vision, Take Two.

The Plan, Take Two.

The Risk List, Take Two.

The Business Case, Take Two.

Digging In (Later Monday).

Pressing On (Tuesday).

More Progress, More Changes (Wednesday).

Nearing Completion (Thursday).

Beta and Ship (Friday).



5. Going Through the Four Phases.

A Major Misconception.

Major Milestones.

No Fixed Workflows.

No Frozen Artifacts.

Three Types of Projects.

6. The Inception Phase.

Objectives of the Inception Phase.

Inception and Iterations.

Objective 1: Understand What to Build.

Produce a Vision Document.

Generate a “Mile-Wide, Inch-Deep” Description.

Hold a Workshop or Brainstorming Session.

Detail Key Actors and Use Cases.

Objective 2: Identify Key System Functionality.

Objective 3: Determine at Least One Possible Solution.

Objective 4: Understand the Costs, Schedule, and Risks Associated with the Project.

Objective 5: Decide What Process to Follow and What Tools to Use.

Project Review: Lifecycle Objective Milestone.


7. The Elaboration Phase.

Objectives of the Elaboration Phase.

Elaboration and Iterations.

First Iteration in Elaboration.

Second Iteration in Elaboration.

Objective 1: Get a More Detailed Understanding of the Requirements.

Objective 2: Design, Implement, Validate, and Baseline the Architecture.

Architecture: Defining Subsystems, Key Components, and Their Interfaces.

Use Architecturally Significant Use Cases to Drive the Architecture.

Design Critical Use Cases.

Consolidate and Package Identified Classes.

Ensure Architectural Coverage.

Design the Database.

Outline Concurrency, Processes, Threads, and Physical Distribution.

Identify Architectural Mechanisms.

Implement Critical Scenarios.

Integrate Components.

Test Critical Scenarios.

What Is Left to Do?

Objective 3: Mitigate Essential Risks, and Produce Accurate Schedule and Cost Estimates.

Plan the Project and Estimate Costs.

Objective 4: Refine the Development Case and Put the Development Environment in Place.

Project Review: Lifecycle Architecture Milestone.


8. The Construction Phase.

Objectives of the Construction Phase.

Construction and Its Iterations.

Objective 1: Minimize Development Costs and Achieve Some Degree of Parallelism.

Organize Around Architecture.

Configuration Management.

Enforce the Architecture.

Ensure Continual Progress.

Objective 2: Iteratively Develop a Complete Product That is Ready to Transition to Its User Community.

Describe the Remaining Use Cases and Other Requirements.

Fill in the Design.

Design the Database.

Implement and Unit-Test Code.

Do Integration and System Testing.

Early Deployments and Feedback Loops.

Prepare for Beta Deployment.

Prepare for Final Deployment.

Project Review: Initial Operational Capability Milestone.


9. The Transition Phase.

Objectives of the Transition Phase.

Transition Iterations and Development Cycles.

Transition and Iterations.

Transition and Development Cycles.

Objective 1: Beta Test to Validate That User Expectations are Met.

Capturing, Analyzing, and Implementing Change Requests.

Transition Testing.

Patch Releases and Additional Beta Releases.

Metrics for Understanding When Transition Will be Complete.

Objective 2: Train Users and Maintainers to Achieve User Self-Reliability.

Objective 3: Prepare Deployment Site and Convert Operational Databases.

Objective 4: Prepare for Launch: Packaging, Production, and Marketing Rollout.

Packaging, Bill of Materials, and Production.

Marketing Rollout.

Objective 5: Achieve Stakeholder Concurrence That Deployment is Complete.

Product Acceptance Test.

Objective 6: Improve Future Project Performance Through Lessons Learned.

Project Review: Product Release Milestone.



10. Configuring, Instantiating, and Customizing the Rational Unified Process.

Configuring the RUP.

Producing a RUP Process Configuration.

Producing Process Views.

Customizing RUP Templates.

Instantiating the RUP in a Project.

A RUP Development Case.

Project Web Site.

Alternatives to Producing a Development Case.

Customizing the RUP.

Rational Process Workbench and Process Engineering Process.

Creating Thin RUP Plug-Ins Using RUP Organizer.

Creating Structural RUP Plug-Ins Using RUP Organizer.


11. Adopting the Rational Unified Process.

Adopting the RUP in a Project.



Configure and Customize.



Adopting the RUP in Small Projects.

Adopting the RUP in a Large Organization.

Process and Tool Enhancement Projects (PTEP).

Pilot Projects.

Software Development Projects.

A Typical Program for Moderate Change.

A Typical Program for Major Change.

An Aggressive Program for Major Change.


12. Planning an Iterative Project.


Key Concepts.






Coarse-Grain and Fine-Grain Plans: Project Plans and Iteration Plans.

The Project Plan.

The Iteration Plan.

Building a Project Plan.

Determining the Number of Iterations.

Iteration Length.

Staffing the Project.

Iteration Planning.

Inception and Elaboration.

Construction and Transition.

Identifying Activities.


An Iterative Estimation Technique: Wideband Modified Delphi.

Optimizing the Project Plan.

Overlapping Iterations.

Parallel Iterations.


13. Common Mistakes When Adopting and Using the RUP--and How to Avoid Them.

Mistakes When Adopting the RUP.

Adopting Too Much of What Is in the RUP.

Adopting Everything at Once, Rather than Incrementally.

Not Planning the Implementation of the RUP.

Not Coupling Process Improvement with Business Results.

Customizing Too Much of the RUP Too Early.

Paying Lip Service to the RUP.

Mistakes When Managing Iterative Development.

Having a Functional, Specialized Organization.

Not Setting the Right Stakeholder Expectations or Using an Old-Fashioned Acquisition Model.

Too Many Developers at Project Start.

Solving the Easy Stuff First.

Having an Extended Initial Iteration.

Having Overlapping Iterations.

Allowing Too Many Changes Late in the Project.

Mistakes in Analysis, Architecture, Design, Implementation, and Testing.

Creating Too Many Use Cases.

Having Analysis-Paralysis.

Including Design Decisions in Your Requirements.

Not Having Stakeholder Buy-In on Requirements.

“Not Invented Here” Mentality.

Ending Elaboration Before the Architecture Is Sufficiently Stable.

Focusing on Inspections Instead of Assessing Executable Software.



14. A Project Manager's Guide to the RUP.

The Mission of a Project Manager.

A Complex Role.

A Person or a Team?

Project Management.

Scope of the Project Management Discipline in the RUP.

Software Development Plan (SDP).

Iterative Development.



Activities of a Project Manager.

Launching a New Project.

Developing the Software Development Plan.

Starting and Closing Phases and Iteration.

Monitoring the Project.

Finding Your Way in the RUP.


Resources for the Project Manager.

Further Reading.

On the Web.

Training Resources.

15. An Analyst's Guide to the RUP.

Your Mission as an Analyst.

Where Do You Start?

Understand How Your Business Should Operate.

Understand Stakeholder Needs.

Develop a Vision.

Problem Statement.

Feature List.

Develop a Use-Case Model and Glossary.

Describe Requirements “Mile-Wide, Inch-Deep”.

Detail Actors and Use Cases.

Example Use-Case Specification for Register for Courses.

Fine-Tune Your Model.

Develop User-Interface Prototypes.

Develop Use-Case Storyboard or Prototype.

Capture Nonfunctional Requirements.

Update and Refine Requirements.

Ensure That the Requirements Are Delivered and Tested.

The Analyst's Role in the Rational Unified Process.

Resources for Analysts.

Further Reading.

Training Resources.

16. An Architect's Guide to the RUP.

The Mission of an Architect.

A Jack-of-All-Trades.

A Person or a Team?

A Vertex of Communication.


Architecture Defined.

Models and Views.

Software Architecture Document.

Executable Architectural Prototype.

Architectural Mechanisms.

Additional Architecture?

An Evolving Role.

What Do Architects Do?






The Architect's Activities in the RUP.

Working with the Requirements and Project Management.

Refining the Architecture.

Maintaining Architectural Integrity.

The Architect's Roles in the RUP.

Finding Your Way in the RUP Product.

Resources for the Architect.

Further Reading.

Useful Web Sites.

17. A Developer's Guide to the RUP.

Your Mission as a Developer.

Overview of the Developer's Tasks.

Understand the Requirements and Design Constraints.

Design, Implement, and Test Use Cases and Components.

Design Use-Case Realizations and Components.

Implement Use Cases and Components.

Developer Testing.

Design, Implement, and Test Any Necessary Databases.

Frequently Integrate Your Application with the Work of Other Developers.

Configuration Management Workspaces.

Integration Planning.

Produce a Build.

Developer Best Practices.

Test First.

Refactor Your Code and Design.

Use Patterns, Architectural Mechanisms, and Other Reusable Assets.

Keep Your Design Simple.

Pair Programming.

The Developer Role in the Rational Unified Process.

Available Resources for Developers.

Recommended Reading.

Recommended Training.

18. A Tester's Guide to the RUP.

The Mission of the Tester.

The Concept of Product Quality in the RUP.

Paradigms of “Good Enough”.

The Cost of Quality.

Wouldn't Quantification Help?.

Conformance to Standards.

What Is Testing?

The RUP Testing Philosophy.


Test Cycles.

The Test Discipline in the RUP Product.

Various Roles Related to Test in the RUP.

Key Test Artifacts.

Activities of the Tester.

Define Test Mission.

Verify Test Approach.

Validate Build Stability (Smoke Test).

Test and Evaluate.

Achieve an Acceptable Mission.

Improve Test Assets.

Other Related Activities.


Resources for Testers.

Further Reading.

Training Resources.

Index. 0321166094T03252003


The Rational Unified Process (RUP) is a software engineering process framework developed and marketed by Rational Software. It comprises many software development best practices, harvested by many contributors, over many years of experience, in a wide variety of situations. It provides a disciplined approach to assigning and managing tasks and responsibilities in a software development organization. By applying this process, software development teams can produce high-quality software that meets the needs of its end users, and do so within a predictable schedule and budget.

The RUP guides software practitioners in effectively applying modern software best practices, such as developing iteratively, taking an architecture-centric approach, mitigating risk at every stage in the process, and continuously verifying the quality of the software. Although thousands of projects today are using the RUP effectively, many teams are intimidated by the thought of implementing a new process that they perceive as large and complex. The RUP does not have to be large, and it is not complex.

The goal of this book is to show you how simple the RUP actually is. It explains the underlying software development principles behind the RUP and guides you in the application of the process in your development organization. It will also show you the way to carve a RUP Process Configuration of the right size for your organization or project.

Why We Wrote This Book

During more than a decade of assisting companies in adopting the RUP and its predecessors, and six years of leading the development of the RUP product, we have had the opportunity to see what works and what does not. We have seen the rewards of successful adoption of the RUP, and we have seen the challenges that projects and team members may encounter along the way. We have also been privileged to work with many leading software practitioners and have learned from them through daily interaction and practical experience in actual projects.

Lately, we have seen a number of companies adopt too much of the RUP. Yes, there is such a thing as "too much of the RUP." We felt there was a need for a book on the RUP that not only tells you what to do, and what artifacts to produce, but also tells you how to streamline your process and what not to do. We wanted to explain how to adopt the RUP in practice, and when to apply what parts of the RUP in a given project. We wanted to help you understand how to apply the RUP to projects of different sizes or of different types.

Through this book, we want to share some of the insights we and our colleagues have gained over the years: Our intent is to provide Project Managers, Analysts, Architects, Developers, Testers, Process Engineers, and other team members and stakeholders with an easy-to-understand guide to the RUP. We have done this by extracting, from our practical experiences with the RUP, the essence of what each role needs to know about the RUP and explaining their role within it.

This book is not a substitute for the RUP product itself. While the book provides a couple of hundred pages of practical guidance, the RUP product provides thousands of pages of direction for a wide array of roles and activities, as well as templates for accelerating your work. It also provides tight integration with desktop tools, a search engine, graphical navigation, and other features you expect from a Web-based knowledge base. Unlike this book, the RUP is continuously evolving, bringing you up-to-date guidance to apply to your projects. Finally, this book will also guide you in customizing the RUP framework to suit your specific needs.

What You Will Learn from This Book

By reading this book, you will learn

  • The RUP's underlying principles, which have been validated by hundreds of successful software projects
  • How these principles are applied in practice, by walking through each phase of a RUP project
  • The roles and responsibilities of Project Managers, Analysts, Architects, Developers, Testers, and Process Engineers in a RUP project
  • How to incrementally adopt the RUP with minimal risk
  • How to identify common patterns for failure, and how to avoid them

Who Should Read This Book?

This book is targeted specifically to

  • All members of a team using, or about to use, the RUP, including Managers who need an introduction and overview of the RUP and who would like to understand its practical application
  • Practitioners on a software project: those Project Managers, Analysts, Architects, Developers, Testers, and Process Engineers who want a detailed understanding of the RUP and their specific role within a RUP project
  • Managers, Process Engineers, and others who want to understand how the RUP can be adopted in their organization

Structure and Contents of This Book

This book is divided into four parts: introduction, walkthrough, adoption, and role-specific guidelines.

Part I introduces the RUP. Chapter 1 explains what the RUP is and the motivation behind its development and its application. Chapter 2, "The Spirit of the RUP," describes the underlying principles behind the RUP--these are based on the experiences gleaned from a number of successful projects and distilled into a few simple guidelines. Understanding these principles will help you better apply the RUP to your own projects. Chapter 3 provides a method for comparing processes, and we use it to compare the RUP to other agile processes, to more conventional processes, and to process assessment frameworks such as SEI CMM and SPICE. These comparisons will help you understand which project type should use what type of RUP configuration. Chapter 4 provides an example that applies the RUP to a very small project: one person for one week. By peeling away the ceremony needed for larger projects, you can focus on the essential elements of the RUP.

Part II presents the RUP by walking through each of the four phases in a RUP project: Inception, Elaboration, Construction, and Transition. Chapter 5 addresses some common misconceptions of the four phases by explaining how the iterative approach applies to them. Chapters 6-9 describe each of the four phases in detail. We focus on what is to be achieved--that is, the objectives of each phase--and guide you in reaching those objectives. This will help you to stay focused on the most essential activities in an actual project. Additionally, we present the RUP activities in a time-based perspective-that is, in the order they are applied in a real project-to give you a reference to understand when to do the activities as you work through a project.

Adopting the RUP requires some preparation and some preliminary knowledge on the part of the adopting organization. Part III provides basic knowledge in key areas to support a streamlined implementation. Chapter 10 walks you through the RUP product, detailing how it can be extended and customized to meet project- and organization-specific needs. Chapter 11 briefly outlines some strategies that may be useful for implementing the process including incremental rollout, pilot projects, and training curricula. Our experience shows that moving from a waterfall approach to iterative development can be a difficult transition for Project Managers, and Chapter 12 provides guidelines for planning a RUP project. Over the years, we have seen patterns of success and patterns of failure in RUP adoptions. Chapter 13 discusses the patterns of failure and how to avoid them, guarding you from repeating the mistakes of others.

The RUP product provides comprehensive guidelines for a wide array of software development activities. Part IV, Chapters 14-18, presents guides for each of the five key roles in any software project: the Project Manager, Analyst, Architect, Developer, and Tester. For each role, we present the RUP from that role's perspective, and we describe the mission, the desired qualifications, and the key activities, as well as recommended reading and training. Note that there is no separate chapter for the Process Engineer: Most of this role is described in Chapters 10 and 11.

How to Read This Book

Based on your role in your software organization and what you want to learn from this book, we recommend the following readings:

If you are looking for a brief overview of the RUP, read Chapters 1, 2, and 4.

If you are looking for a detailed overview of the RUP, read Chapters 1-9.

If you are looking for a detailed understanding of the RUP, including specific role responsibilities:

  • For Project Managers, read Chapters 1-9 and 11-14.
  • For Analysts, read Chapters 1-9, 13, and 15 (optionally, browse through Chapters 8 and 9).
  • For Architects, read Chapters 1-9, 13, and 16.
  • For Developers, read Chapters 1-9, 13, and 17 (optionally, browse through Chapter 6).
  • For Testers, read Chapters 1-9, 13, and 18.
  • For Process Engineers, read Chapters 1-11 and 13.
  • If you are an executive looking for a brief overview of the RUP, and what it takes to adopt the RUP, read Chapters 1, 2, 4, and 11.

For More Information

Additional information about the RUP product, including a data sheet and a product demo, can be obtained from Rational Software at http://www.rational.com/products/rup.

If you are already using the RUP product, additional resources are available from the RUP Knowledge Center on the Rational Developer Network (RDN) at http://www.rational.net.

Academic institutions can contact Rational Software for information on a special program for including the RUP in a software engineering curriculum: http://www.rational.com/corpinfo/college_relations/seed/index.jsp.



Every software development team follows some sort of process, whether intentionally or not. In small teams of one, two, or just a handful of developers, that process is typically lightweight. Very few if any documents are produced, analysis and design does take place but is often informal and transitory, and the project's source code serves as the center of gravity around which all other activities of the project orbit.

In large teams of dozens or even hundreds of developers, typically spread across buildings or flung around the globe, that process is much more prescribed. Many more formal and officially reviewed documents are produced; analysis and design involves the collaboration of a number of nondeveloper stakeholders and is made manifest in meetings, presentations, documents, and other artifacts; and the project's code is just one--albeit the most important of the tangible artifacts that compose the deployed system. This is not to say that lightweight processes and heavier ones are at opposite ends of the spectrum of goodness: Every problem domain, every development culture, and every individual project requires a process that is just right for its specific context.

That said, all successful projects have some fascinating elements in common, no matter what their size. These elements are notably absent in unsuccessful projects. Observe a jelled project and you'll sense a distinct rhythm of cooperative work, with individual developers driving their own activities and ers. Such projects are typically quite agile, resilient to change, and adaptable, but also predictable, reliable, and able to craft quality code that really matters. In short, for these projects, the process followed is so much a ible, yet its spirit moves every artifact produced by team members working in concert.

The spirit of the Rational Unified Process, or RUP, is exactly this kind of invisible process. The RUP has evolved over the years to embody the experience of literally thousands of projects in every conceivable domain. Per Kroll and Philippe Kruchten are especially well suited to explain the RUP in an approachable and eminently pragmatic way because they have been the central forces inside Rational Software behind the creation of the RUP and its delivery to projects around the world.

When you talk about process to many developers, there is often an immediate push back because process is so often viewed as something that gets in the way of cutting code. This is simply not so with the RUP, for its very purpose is to reduce the friction of development teams so that they may focus on producing quality systems that are of value. Per and Philippe begin by explaining the spirit of the RUP and then proceed to show how the RUP may be applied to projects of many different shapes and sizes.

After explaining the pragmatics of the RUP, they then discuss several meta topics, including how you can introduce the RUP to an organization and what pitfalls to avoid in doing so. Making the RUP approachable to different stakeholders, they then examine the RUP from the viewpoint of the project manager, analyst, architect, developer, and tester.

The most successful project makes process look easy, but in reality, some really deep currents are at work. In this book, Per and Philippe explain those currents in an approachable and practical way, so that your projects too will follow the spirit of the RUP.

Grady Booch
Chief Scientist
Rational Software Corporation
February 2003


Click below to download the Index file related to this title:


Submit Errata

More Information

Unlimited one-month access with your purchase
Free Safari Membership