The Unified Software Development Process

Hardcover (Print)
Buy Used
Buy Used from
(Save 38%)
Item is in good condition but packaging may have signs of shelf wear/aging or torn packaging.
Condition: Used – Good details
Used and New from Other Sellers
Used and New from Other Sellers
from $1.99
Usually ships in 1-2 business days
(Save 97%)
Other sellers (Hardcover)
  • All (35) from $1.99   
  • New (5) from $11.95   
  • Used (30) from $1.99   
Sort by
Page 1 of 1
Showing All
Note: Marketplace items are not eligible for any coupons and promotions
Seller since 2015

Feedback rating:



New — never opened or used in original packaging.

Like New — packaging may have been opened. A "Like New" item is suitable to give as a gift.

Very Good — may have minor signs of wear on packaging but item works perfectly and has no damage.

Good — item is in good condition but packaging may have signs of shelf wear/aging or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Acceptable — item is in working order but may show signs of wear such as scratches or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Used — An item that has been opened and may show signs of wear. All specific defects should be noted in the Comments section associated with each item.

Refurbished — A used item that has been renewed or updated and verified to be in proper working condition. Not necessarily completed by the original manufacturer.

Ships same day as ordered on most orders. Brand new.

Ships from: Lansing, KS

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
Seller since 2015

Feedback rating:


Condition: New
0201571692 Excellent Buy!!!

Ships from: Pleasant View, TN

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
Seller since 2008

Feedback rating:


Condition: New

Ships from: Chicago, IL

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
Seller since 2015

Feedback rating:


Condition: New
Brand new.

Ships from: acton, MA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
Seller since 2015

Feedback rating:


Condition: New
Brand new.

Ships from: acton, MA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
Page 1 of 1
Showing All
Sort by


This landmark book provides a thorough overview of the Unified Process for software development, with a practical focus on modeling using the Unified Modeling Language (UML). The Unified Process goes beyond mere object-oriented analysis and design to spell out a proven family of techniques that supports the complete software development life cycle. The result is a component-based process that is use-case driven, architecture-centric, iterative, and incremental.

The Unified Process takes full advantage of the industry-standard Unified Modeling Language. This book demonstrates how the notation and process complement one another, using UML models to illustrate the new process in action. The authors clearly describe the semantics and notation of the different higher-level constructs used in the models. Constructs such as use cases, actors, subsystems, classes, interfaces, active classes, processes, threads, nodes, and most relations are described in the context of a model. Object technology practitioners and software engineers familiar with the authors' past work will appreciate The Unified Software Development Process as a useful means of learning the current best practices in software development.


Ivar Jacobson, Grady Booch and James Rumbaugh have done it again. Written by the original designers of UML, this book details a unified software development process intended to be used with UML. With charts and examples, it examines use cases, architecture, and iterative and incremental development. The guide targets software developers dealing with lifecycle activities requirements, analysis, design, implementation and testing.

Read More Show Less

Editorial Reviews

From Barnes & Noble
The Barnes & Noble Review

The Unified Modeling Language (UML) offers a powerful, standardized way to visualize, specify, construct, and document software systems, but it's a means, not an end in itself. As its founders observe, UML "must be used within the context of an end-to-end software process." In this widely anticipated book, Jacobson, Booch and Rumbaugh describe their Unified Process in depth for the first time.

In a nutshell, the Unified Process is use-case driven, architecture-centric, iterative and incremental. The authors explain what they mean by each of these elements in considerable detail, discussing why each is equally important, and how they all fit together.

The Unified Software Development Process covers the entire lifecycle, but focuses most on the activities UML itself focuses on: identifying requirements and capturing them as use cases; performing analysis; and building a design that reflects the requirements and analysis. There's detailed coverage of workflow throughout each iteration of the process, including inception, elaboration, construction, and transition.

It may take a little while to get your arms around all the ideas in this book. But once you do, you'll know how to build processes that can systematically achieve the benefits of object modeling, while remaining flexible enough for the chaotic real world we live in. — Review by Bill Camarda (Contributing Editor)

Eduardo Fernandez

Ivar Jacobson is generally considered the "father" of use cases. He appears to have written most of this book, and in a more general sense, he has clearly convinced Rational to build its development process around this concept. In The Unified Software Development Process, Jacobson comes across as a preacher out to convince lost souls about his truth.

For instance, on page 34 he states that "use cases drive the development process." In my experience, this is not necessarily the case. The main value of use cases is during the analysis stage and when developing system test cases. In truth, they don't help much at the design and implementation stages. For example, use cases do not carry information about structural aspects of the system and nonfunctional aspects. Nor, for that matter, do other process approaches (such as those described in Object-Oriented Development at Work: Fusion In the Real World, by R. Malan, R. Letringer, and D. Coleman, Prentice-Hall, 1996, or Use Cases Combined with Booch/OMT/UML: Process and Products, by P.P. Texel and C.B. Williams, Prentice-Hall, 1997), give such prominence to use cases.

The Unified process does not make a clear distinction between analysis and design; its analysis model uses controller and view classes. In my opinion (as well as James Rumbaugh's; see "OMT: The Development Process," JOOP, May 1995 -- why didn't he speak up here?), these classes are software artifacts and don't belong here. In fact, this separation of classes is just an application of an architectural design pattern -- the MVC -- which is not even mentioned in The Unified Software Development Process. No mention of analysis patterns can be found either, even though they will likely become very important to produce correct models of complex systems.

The discussion of architecture (page 83) doesn't consider important aspects such as mapping to hardware, distribution, serious use of architectural patterns, and the like. Design patterns also don't have an important role here.

Components are defined as "physical packaging of model elements;" that is, they are just the resulting implementations of the model classes. How about the use of components in a more modern fashion, JavaBeans, for instance, as done in the Nokia process (see "Extending the Object-Oriented Software Process with Component-Oriented Design," by M. Laitkorpi and A. Jaaksi, JOOP March-April 1999). In fact, components do not even have to be object based.

Although Rational is a well-known producer of tools, the process described in The Unified Development Process surprisingly doesn't make a significant use of tools. Three pages discuss tools in general at the beginning of the book and tools are briefly mentioned later, but there is no clear integration with the proposed process. Likewise, testing is also dealt with rather superficially. The chapter on testing deals mostly with integration testing. There is almost nothing on class testing; for example, the authors of The Unified Development Process don't consider the use of pre- and postconditions and other important issues. What is worse, the concept that testing should be applied at all stages of development is not considered. The references in this section reflect a lack of awareness of progress in this area.

On the upside, at least in terms of practical value, the book provides a clear definition and separation of roles and people involved in the process. This is probably the strongest point of the Unified process described in the book. The running examples are good and help the reader to understand the concepts. They should have been given more importance. Some data on the experience of using this approach would have been useful.

The style is clear, but verbose. More examples, diagrams, and discussion of cases would have been more appropriate than so many philosophical discussions about the value of their approach. Pages 441-480, for instance, are a glossary -- the need for which I cannot understand in an advanced book like this. Do readers need to be told what an "object" or "state" is?

In summary, The Unified Software Development Process should be taken as a user manual for anyone already using or contemplating use of the Rational process. It doesn't provide much insight on how this approach compares to other approaches. Most of the references are to the work of Rational people, the process models of others are ignored. The book doesn't much help somebody looking for a possible process to use. Truly, this is not a scholarly book, but it would have been nice to see how they compare their approach to others.

There is no doubt that the authors have a good deal of knowledge and experience. My objections are to the biased approach and the lack of comparison with other approaches. This book looks too much like a typical vendor book, i.e. "We invented everything." Also, Jacobson has completely smothered Rumbaugh and Booch here; their process philosophies don't shine through. What is worse, the Unified process as described here appears antiquated because of its lack of emphasis on patterns and components.

I am not saying that you cannot learn something from The Unified Software Development Process, but I found it disappointing, especially after seeing the other two volumes by this trio.
Electronic Review of Computer Books

This guide overviews the Unified Process for software development, with a focus on modeling using the Unified Modeling Language (UML). It demonstrates how the notation and process complement on another, using UML models to illustrate the new process in action. The authors describe semantics and notation of the different higher-level constructs used on the models. Constructs such as use cases, actors, subsystems, classes, interfaces, active classes, processes, threads, nodes, and most relations are described in the context of a model. ^^^^ Annotation c. Book News, Inc., Portland, OR (
Read More Show Less

Product Details

  • ISBN-13: 9780201571691
  • Publisher: Addison-Wesley
  • Publication date: 1/28/1999
  • Series: Addison-Wesley Object Technology Series
  • Edition description: New Edition
  • Pages: 512
  • Product dimensions: 7.72 (w) x 9.55 (h) x 1.24 (d)

Meet the Author

Ivar Jacobson, Ph.D., is “the father” of many technologies, including components and component architecture, use cases, modern business engineering, and the Rational Unified Process. He was one of the three amigos who originally developed the Unified Modeling Language. He is the principal author of five best-selling books on these methods and technologies, in addition to being the coauthor of the two leading books on the Unified Modeling Language. Ivar is a founder of Jaczone AB, where he and his daughter and cofounder, Agneta Jacobson, are developing a ground-breaking new product that includes intelligent agents to support software development. Ivar also founded Ivar Jacobson Consulting (IJC) with the goal of promoting good software development practices throughout teams worldwide.

Grady Booch, is the Chief Scientist at Rational Software Corporation and developer of the Booch Method of object-oriented analysis and design. He is also co-developer of the Unified Modeling Language (UML). Widely recognized for these and many contributions in the field, he is a popular speaker at technology conferences around the world. Booch has twice received Software Development magazine's coveted Jolt-Cola Product Excellence Award for his seminal text, Object-Oriented Analysis and Design with Applications. Dr. James Rumbaugh is one of the leading object-oriented methodologists. He is the chief developer of the Object Modeling Technique (OMT) and the lead author of the best-selling book Object-Oriented Modeling and Design. Before joining Rational Software Corporation in October 1994, he worked for more than 25 years at General Electric Research and Development Center in Schenectady, New York.

He has been working on object-oriented methodology and tools for many years. He developed the DSM object-oriented programming language, the state tree model of control, the OMT object modeling notation, and the Object Modeling Tool graphic editor. The foundations for the OMT notation were developed more than 10 years ago with Mary Loomis and Ashwin Shah of Calma Corporation. The OMT methodology was developed at GE R&D Center with coauthors Mike Blaha, Bill Premerlani, Fred Eddy, and Bill Lorensen.

Dr. Rumbaugh received his Ph.D. in computer science from MIT. During his Ph.D. research under Professor Jack Dennis, Dr. Rumbaugh was one of the inventors of data flow computer architecture. His career has dealt with semantics of computation, tools for programming productivity, and applications using complex algorithms and data structures. Dr. Rumbaugh has published journal articles on his work and has spoken at leading object-oriented conferences. He writes a regular column for the Journal of Object-Oriented Programming.

Dr. Rumbaugh is the lead author of the recent best-selling book Object-Oriented Modeling and Design, published by Prentice Hall. His latest book, OMT Insights: Perspectives on Modeling from the Journal of Object-Oriented Programming, was released in October 1996. He and his colleagues developed the OMT methodology described in the book based on real-world applications at GE, and they have worked to extend the original methodology. He has taught courses based on the methodology to different audiences around the world, ranging from one-hour seminars to intensive several-day training courses.

He has a B.S. in physics from MIT, an M.S. in astronomy from Caltech, and a Ph.D. in computer science from MIT.

During his career at GE, he worked on a variety of problems, including the design of one of the first time-sharing operating systems, early work in interactive graphics, algorithms for computed tomography, use of parallel machines for fast image generation, VLSI chip design, and finally, object-oriented technology.

Jim developed OMTool, an interactive graphical editor for manipulation of object model diagrams. The editor is commercially available. In addition, he led a five-year programming effort producing production-quality software.

In addition, Jim was the manager of the Software Engineering Program at GE, where he led a team of eight to ten Ph.D. and M.S. scientists performing research in software engineering in the areas of algorithm development, programming languages, program proving, and VLSI computer-aided design. In addition, he performed personal research.

Jim developed Chipwright, an interactive graphical CAD system for VLSI layout with incremental design rule checking. He also led a team of four programmers in implementation.

Jim developed and implemented the object-oriented language DSM, combining object-oriented concepts with database concepts and distributed it within GE for use on production applications. The language was heavily used at Calma Corporation and was extensively extended based on user feedback with a preliminary version.

Jim also developed Vista, a hierarchical interactive standard graphics system (similar to the PHIGS system) written in the object-oriented DSM language. He implemented user-interface applications based on this system, including a configuration-management tool and a user-interface generation tool.

Jim developed the concept of state trees, a structured extension of finite state machines incorporating a new model of object-oriented control. He applied it to the design of user interfaces, and the technique was used as a main aspect of the CHIDE user-interface system developed by colleagues at GE-CRD. Later, it was used in the OMTool object editor.

Jim also developed the Flow Graph System, a generic interactive graphic system for controlling a network of design engineering jobs, including management of multiple versions of data and coordination of information flow among applications. He received a patent on the underlying concepts.

In addition, Jim developed algorithms for the reconstruction of images for computerized tomography using fewer input points and with reduced noise in the reconstructed images. He also developed algorithms for display of three-dimensional images in real time using array processors, and he developed Parallax, a language for programming pipelined array processors.

Jim has served on various committees, including the OOPSLA Program Committee and the TOOLS Program Committee.

Read More Show Less

Read an Excerpt

Chapter 6: Requirements Capture: From Vision To Requirements

For generations, certain Native American tribes built a kind of canoe, called a dugout, made of a hollowed-out log. The canoe builders began by looking for a tree that was several feet in diameter that had already toppled over near the water. Near it, they lit a fire and spread the hot coals on the top of the log. The charred wood was much easier to hollow out with stone tools. After several days of carving, the canoe would appear to be complete, and the builders would push and pull it into shallow water. More than likely, the first rough effort simply rolled over. It was not balanced. More work with those dull stone tools followed, until they had a boat that did not capsize when someone bent over to pull a fish out of the water. Only then did they call it finished. This knowledge had been passed from generation to generation and had made its way to the builders' very backbones.

When a "tribe" of software developers hears the call to develop a new system, they face a far different situation. First of all, the developers will not be the future users of the system. They will not reflexively get immediate feedback about how their "dugout" performs. Second, the system's requirements and constraints have not been ingrained into their "backbones" through continuous product usage since childhood. Instead, they will have to discover for themselves what is needed.

We call this act of discovery requirements capture. It is the process of finding out, usually under difficult circumstances, what is to be built. In fact, it is so difficult that it is still not uncommon for project teams to start writing code (whichis fairly easy) before they have firmed up just what the code is supposed to do (which is difficult).

6.1 Why Requirements Capture Is Difficult

Professional software developers usually build software for someone other than themselves-they build it for users of the software. "Ahal" developers used to say, "the users must know what they require." However, a little experience trying to gather requirements from users soon reveals them to be an imperfect source of information. For one thing, any system usually has many users (or types of users), and while each user may know what he or she does, no one can see the whole picture. Users don't know how the operation as a whole can be made more efficient. Most users don't know which aspects of their work can be turned over to software. Frankly, users frequently do not know what the requirements are or how to specify them in a precise manner, either.

The traditional approach to this problem has been to assign intermediaries analysts-to elicit a list of requirements from each user with the hope that the analyst would be able to see the whole picture and put together a complete, correct, and consistent requirements specification. Analysts typically recorded the requirements in documents that ran to hundreds, sometimes thousands, of pages. But it is absurd to believe that the human mind can come up with a consistent and relevant list of thousands of requirements in the form "The system shall What's more, these requirements specifications did not readily transform into design and implementation specifications.

Even with the help of analysts, users did not fully understand what the software system ought to do until the system was almost completed. As projects proceeded and users, intermediaries, and the developers themselves could see what the system would look like and thus came to understand the real needs better, a wealth of changes would be suggested. Many of these changes were desirable, but implementing them usually had a serious impact on schedules and costs.

Over the years we have fooled ourselves into believing that users know what the requirements are and that all we have to do is interview them. It is true that the systems we build should support users and that that we can learn about user interaction from the users themselves. However, it is even more important that systems support the mission for which they are built. For example, the system should provide value to the business that uses it and to its customers. Often, it is difficult to identify or understand what this value is, and sometimes it is impossible to have the system satisfy the value. Worse, in a reflection of the ever-changing real world, this elusive value will likely change during the course of the project: The business itself might change, the technology available to build the system might change, the resources (people, money) available to build the system might change, and so on.

Even with this insight, requirements capture remains difficult, and the industry has long sought a good, systematic process to do it. To that we turn our attention in this chapter and the following.

6.2 The Purpose Of The Requirements Workflow

The essential purpose of the requirements workflow is to aim development toward the right system. This is achieved by describing the system requirements (i.e., the conditions or capabilities to which the system must conform) well enough so that an agreement can be reached between the customer (including the users) and the system developers on what the system should and should not do.

A major challenge with this is that the customer, who we assume to be primarily a noncomputer specialist, must be able to read and understand the results of requirements capture. To meet this challenge we must use the language of the customer to describe these results. As a consequence, we should be very careful when introducing formality and structure and when introducing details about the system's internal workings, in the results.

The results of the requirements workflow also helps the project manager plan the iterations and customer releases (this is discussed in Part III).

6.3 Overview Of Requirements Capture

Every software project is unique. This singularity comes from the variations in the kind of system, the customer, the development organization, the technology, and so on. Similarly, there are different starting points for capturing requirements. In some cases, we start by developing a business model, or we start with a business model already under development by some other organization (see Section 6.6.1, "What Is a Business Model?"). In other cases, the software is an embedded system that does not directly support a business. Then there might be a simple object model, such as a domain model, to serve as input (see Section 6.5.1, "What Is a Domain Model?"). In still other cases, the client may have already developed a complete, detailed requirements specification that is not based on an object model, from which we start and negotiate changes.

At the other extreme are customers who have only a vague notion of what their system should be-perhaps it is derived from a vision statement issued by top management. In between these extremes are all varieties of combinations. We will consider one such starting point, the "vague notion," and introduce the example that we will use in the rest of this book.

The Interbank Consortium Considers a Computer System

The Interbank Consortium, a hypothetical financial institution, is facing major changes due to deregulation, new competition, and capabilities enabled by the World Wide Web. The consortium plans to develop new applications to support the rapidly changing finance markets. It has directed its software development subsidiary, Interbank Software, to initiate the development of these applications.

Interbank Software decides to design the Billing and Payment System in collaboration with some of its main bank customers. The system will use the Internet for sending orders, invoices, and payments between buyers and sellers. The bank's motivation for developing the system is to attract new customers by offering a low payment- processing fee. The bank will also be able to reduce its wage costs by processing payment requests automatically through the Internet instead of manually through cashiers. The motivations for buyers and sellers are to reduce costs, paperwork, and processing time. For example, they will no longer have to send orders or invoices by paper mail. The payment of invoices will be handled between the buyer's computer and the seller's computer. Buyers and sellers will also have a better overview of the status of their invoices and payments.

The possibility of such different starting points as a vague vision statement and a detailed requirements specification suggests that analysts need to be able to adapt their approach to requirements capture to each situation. Different starting points pose different types of risks, so analysts should choose the approach that will best reduce those risks. Risk reduction is discussed in detail in Part 111. Despite the differences in starting points, certain steps are feasible in most cases, which allows us to suggest an archetypal workflow. This workflow includes the following steps, which are not actually performed separately:

  • List candidate requirements.
  • Understand system context.
  • Capture functional requirements.
  • Capture nonfunctional requirements.
We will briefly describe these steps in the following paragraphs.

List candidate requirements During the life of a system, customers, users, analysts, and developers come up with many good ideas that might turn into real requirements. We keep a list of these ideas, which we think of as a set of candidate requirements that we may chose to implement in some future release of the system. This feature list grows as new items are added and shrinks as features become requirements and are transformed into other artifacts, such as the use cases. The feature list is used only for planning the work. Each feature has a short name and a brief explanation or definition, just enough information to be able to talk about the feature during product planning. Each feature also has a set of planning values, which might include

  • Status (e.g., proposed, approved, incorporated, or validated);
  • Estimated cost to implement (in terms of resource types and man-hours);
  • Priority (e.g., critical, important, or ancillary); and
  • Associated level of risk in implementing the feature (e.g., critical, significant, or ordinary: see Chapter 5) . . .
Read More Show Less

Table of Contents



1. The Unified Process: Use-Case Driven, Architecture-Centric, Iterative, and Incremental.

The Unified Process in a Nutshell.

The Unified Process Is Use-Case Driven.

The Unified Process Is Architecture-Centric.

The Unified Process Is Iterative and Incremental.

The Life of the Unified Process.

The Product.

Phases within a Cycle.

An Integrated Process.

2. The Four Ps: People, Project, Product, and Process in Software Development.

People Are Crucial.

Development Processes Affect People.

Roles Will Change.

Turning “Resources” into “Workers.”

Projects Make the Product.

Product Is More Than Code.

What Is a Software System?


A System Has a Collection of Models.

What Is a Model?

Each Model Is a Self-Contained View of the System.

Inside a Model.

Relationships between Models.

Process Directs Projects.

Process: A Template.

Related Activities Make Up Workflows.

Specializing Process.

Merits of Process.

Tools Are Integral to Process.

Tools Impact Process.

Process Drives Tools.

Balance Process and Tools.

Visual Modeling Supports UML.

Tools Support the Whole Life Cycle.


3. A Use-Case-Driven Process.

Use-Case-Driven Development in Brief.

Why Use Cases?

To Capture the Value Adding Requirements.

To Drive the Process.

To Devise the Architecture and More...

Capturing the Use Cases.

The Use-Case Model Represents the Functional Requirements.

Actors Are the Environment of the System.

Use Cases Specify the System.

Analysis, Design, and Implementation to Realize the Use Cases.

Creating the Analysis Model from the Use Cases.

Each Class Must Fulfill All Its Collaboration Roles.

Creating the Design Model from the Analysis Model.

Subsystems Group Classes.

Creating the Implementation Model from the Design Model.

Testing the Use Cases.

Summing Up.


4. An Architecture-Centric Process

Architecture in Brief.

Why We Need Architecture.

Understanding the System.

Organizing Development.

Fostering Reuse.

Evolving the System.

Use Cases and Architecture.

The Steps to an Architecture.

The Architecture Baseline Is a “Small, Skinny” System.

Using Architecture Patterns.

Describing Architecture.

The Architect Creates the Architecture.

Finally, an Architecture Description!

The Architectural View of the Use-Case Model.

The Architectural View of the Design Model.

The Architectural View of the Deployment Model.

The Architectural View of the Implementation Model.

Three Interesting Concepts.

What Is Architecture?

How Is It Obtained?

How Is It Described?


5. An Iterative and Incremental Process.

Iterative and Incremental in Brief.

Develop in Small Steps.

What Iteration Is Not.

Why Iterative and Incremental Development?

Mitigating Risks.

Getting a Robust Architecture.

Handling Changing Requirements.

Allowing for Tactical Changes.

Achieving Continuous Integration.

Attaining Early Learning.

The Iterative Approach is Risk-Driven.

Iterations Alleviate Technical Risks.

Management Is Responsible for Nontechnical Risks.

Dealing with Risks.

The Generic Iteration.

What an Iteration Is.

Planning the Iterations.

Sequencing the Iterations.

The Result of an Iteration Is an Increment.

Iterations over the Life Cycle.

Models Evolve from Iterations.

Iterations Challenge the Organization.



6. Requirements Capture: From Vision to Requirements.

Why Requirements Capture Is Difficult.

The Purpose of the Requirements Workflow.

Overview of Requirements Capture.

The Role of Requirements in the Software Life Cycle.

Understanding the System Context Using a Domain Model.

What Is a Domain Model?

Developing a Domain Model.

Use of the Domain Model.

Understanding the System Context Using a Business Model.

What Is a Business Model?

How to Develop a Business Model.

Find Use Cases from a Business Model.

Supplementary Requirements.



7. Capturing the Requirements as Use Cases.



Artifact: Use-Case Model.

Artifact: Actor.

Use Case.

Artifact: Architecture Description (View of the Use-Case Model).

Artifact: Glossary.

Artifact: User-Interface Prototype.


Worker: System Analyst.

Worker: Use-Case Specifier.

User-Interface Designer.

Worker: Architect.


Activity: Find Actors and Use Cases.

Activity: Prioritize Use Cases.

Activity: Detail a Use Case.

Activity: Prototype User Interface.

Activity: Structure the Use-Case Model.

Summary of the Requirements Workflow.


8. Analysis.


Analysis in Brief.

Why Analysis Is not Design or Implementation.

The Purpose of Analysis: Summary.

Concrete Examples of When to Employ Analysis.

The Role of Analysis in the Software Life Cycle.


Artifact: Analysis Model.

Artifact: Analysis Class.

Artifact: Use-Case Realization—Analysis.

Artifact: Analysis Package.

Artifact: Architecture Description (View of the Analysis Model).


Worker: Architect.

Worker: Use-Case Engineer.

Worker: Component Engineer.


Activity: Architectural Analysis.

Activity: Analyze a Use Case.

Activity: Analyze a Class.

Activity: Analyze a Package.

Summary of Analysis.


9. Design.


The Role of Design in the Software Life Cycle.


Artifact: Design Model.

Artifact: Design Class.

Artifact: Use-Case Realization—Design.

Artifact: Design Subsystem.

Artifact: Interface.

Artifact: Architecture Description (View of the Design Model).

Artifact: Deployment Model.

Artifact: Architecture Description (View of the Deployment Model).


Worker: Architect.

Worker: Use-Case Engineer.

Worker: Component Engineer.


Activity: Architectural Design.

Activity: Design a Use Case.

Activity: Design a Class.

Activity: Design a Subsystem.

Summary of Design.


10. Implementation.


The Role of Implementation in the Software Life Cycle.


Artifact: Implementation Model.

Artifact: Component.

Artifact: Implementation Subsystem.

Artifact: Interface.

Artifact: Architecture Description (View of the Implementation Model).

Artifact: Integration Build Plan.


Worker: Architect.

Worker: Component Engineer.

Worker: System Integrator.


Activity: Architectural Implementation.

Activity: Integrate System.

Activity: Implement a Subsystem.

Activity: Implement a Class.

Activity: Perform Unit Test.

Summary of Implementation.


11. Test.


The Role of Testing in the Software Life Cycle.


Artifact: Test Model.

Artifact: Test Case.

Artifact: Test Procedure.

Artifact: Test Component.

Artifact: Plan Test.

Artifact: Defect.

Artifact: Evaluate Test.


Worker: Test Designer.

Worker: Component Engineer.

Worker: Integration Tester.

Worker: System Tester.


Activity: Plan Test.

Activity: Design Test.

Activity: Implement Test.

Activity: Perform Integration Test.

Activity: Perform System Test.

Activity: Evaluate Test.

Summary of Testing.



12. The Generic Iteration Workflow.

The Need for Balance.

The Phases Are the First Division of Work.

Inception Phase Establishes Feasibility.

Elaboration Phase Focuses on “Do-Ability.”

Construction Phase Builds the System.

Transition Phase Moves into the User Environment.

The Generic Iteration Revisited.

Core Workflows Repeat in Each Iteration.

Workers Participate in the Workflows.

Planning Precedes Doing.

Plan the Four Phases.

Plan the Iterations.

Think Long Term.

Plan the Evaluation Criteria.

Risks Affect Project Planning.

Manage a Risk List.

Risks Affect the Iteration Plan.

Schedule Risk Action.

Use-Case Prioritization.

Risks Specific to a Particular Product.

Risk of Not Getting the Architecture Right.

Risk of Not Getting Requirements Right.

Resources Needed.

Projects Differ Widely.

A Typical Project Looks Like This.

Complex Projects Have Greater Needs.

New Product Line Calls for Experience.

Paying the Cost of the Resources Used.

Assess the Iterations and Phases.

Criteria Not Achieved.

The Criteria Themselves.

The Next Iteration.

Evolution of the Model Set.

13. Inception Launches the Project.

The Inception Phase in Brief.

Early in the Inception Phase.

Before the Inception Phase Begins.

Planning the Inception Phase.

Expanding the System Vision.

Setting the Evaluation Criteria.

The Archetypal Inception Iteration Workflow.

Introduction to the Five Core Workflows.

Fitting the Project into the Development Environment.

Finding Critical Risks.

Execute the Core Workflows, Requirements to Test.

Capture the Requirements.




Make the Initial Business Case.

Outline Business Bid.

Estimate Return on Investment.

Assess the Iteration(s) in the Inception Phase.

Planning the Elaboration Phase.

The Deliverables for the Inception Phase.

14. The Elaboration Phase Makes the Architectural Baseline.

The Elaboration Phase in Brief.

Early in the Elaboration Phase.

Planning the Elaboration Phase.

Building the Team.

Modifying the Development Environment.

Setting Evaluation Criteria.

The Archetypal Elaboration Iteration Workflow.

Capture and Refine Most of the Requirements.

Develop the Architectural Baseline.

Iterate While the Team Is Small.

Execute the Core Workflows—Requirements to Test.

Capture the Requirements.





Make the Business Case.

Prepare the Business Bid.

Update Return on Investment.

Assess the Iterations in the Elaboration Phase.

Planning the Construction Phase.

The Key Deliverables.

15. Construction Leads to Initial Operational Capability.

The Construction Phase in Brief.

Early in the Construction Phase.

Staffing the Phase.

Setting the Evaluation Criteria.

The Archetypal Construction Iteration Workflow.

Execute the Core Workflows—Requirements to Testing.






Controlling the Business Case.

Assess the Iterations and the Construction Phase.

Planning the Transition Phase.

The Key Deliverables.

16. Transition Completes Product Release.

The Transition Phase in Brief.

Early in the Transition Phase.

Planning the Transition Phase.

Staffing the Transition Phase.

Setting the Evaluation Criteria.

The Core Workflows Play a Small Role in this Phase.

What We Do in the Transition Phase.

Getting the Beta Release Out.

Installing the Beta Release.

Responding to the Test Results.

Adapting the Product to Varied User Environments.

Completing the Artifacts.

When Does the Project End?

Completing the Business Case.

Controlling Progress.

Review of the Business Plan.

Assess the Transition Phase.

Assess the Iterations and the Phase.

Postmortem of the Project.

Planning the Next Release or Generation.

The Key Deliverables.

17. Making the Unified Process Work.

The Unified Process Helps You Deal with Complexity.

The Life Cycle Objectives.

The Life Cycle Architecture.

Initial Operational Capability.

Product Release.

The Major Themes.

Management Leads Conversion to Unified Process.

The Case for Action.

The Reengineering Directive Persuades.

Implementing the Transition.

Specializing the Unified Process.

Tailoring the Process.

Filling in the Process Framework.

Relate to the Broader Community.

Get the Benefits of the Unified Process.


Appendix A: Overview of the UML.



Extensibility Mechanisms.

Graphical Notation.

Structural Things.

Behavioral Things.

Grouping Things.

Annotational Things.

Dependency Relationships.

Association Relationships.

Generalization Relationships.

Extensibility Mechanisms.

Glossary of Terms.


Appendix B: The Unified Process-Specific Extensions of the UML.



Tagged Values.

Graphical Notation.


Appendix C: General Glossary.



Index. 0201571692T04062001

Read More Show Less


<@INCLUDE include/titles/0-201-57169-2/preface>


Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star


4 Star


3 Star


2 Star


1 Star


Your Rating:

Your Name: Create a Pen Name or

Barnes & Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation


  • - By submitting a review, you grant to Barnes & and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Terms of Use.
  • - Barnes & reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing all of 3 Customer Reviews
  • Anonymous

    Posted March 2, 2005

    Not worth a penny

    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.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted March 10, 2003

    Let's Understand the Process....

    One of the best book I came across.. This is for those people who are not using processes in their projects.... and then resolving problems faced in project.. This book will give them a clear idea. What process is ? and how to use it effectively.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted July 21, 2000

    An excellent book.

    This book is brilliant and represents the culmination of years of work on software development process. As the UML strives to define the 'calculus' of software engineering, this process book outlines a suggested process for software development using the UML notation. If you are trying to learn UML notation, I would recommend this book as a starting point. It does not bog the reader down in the details of UML notation. It provides a template for software development, a pattern some would say. This process book describes which artifacts to produce during each phase of software development and shows tracing between these artifacts.

    Was this review helpful? Yes  No   Report this review
Sort by: Showing all of 3 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)