It looks like you're offline.

An edition of The unified software development process (1999)

The unified software development process

by Ivar Jacobson

11 Want to read

Cover of: The unified software development process by Ivar Jacobson, Ivar Jacobson

Preview

Search

Nearby Libraries

Only a preview is available.

11 Want to read

Last edited by MARC Bot

July 22, 2025 | History

Edit

An edition of The unified software development process (1999)

The unified software development process

by Ivar Jacobson

11 Want to read

The Unified Process is the result of a merger and refinement of popular object-oriented methods, following on from the success of UML.

Publish Date

1999

Publisher

Addison-Wesley

Language

English

Pages

463

Previews available in: English

Edition	Availability
1 Le Processus unifié de développement logiciel June 23, 2000, Eyrolles Paperback in French 2212091427 9782212091427	zzzz Nearby Libraries
2 El Proceso Unificado de Desarrollo de Software November 2000, Addison Wesley Publishing Company, ADDISON WESLEY Paperback 8478290362 9788478290369	zzzz Nearby Libraries
3 The unified software development process 1999, Addison-Wesley in English 0201571692 9780201571691	aaaa Preview Only
4 Unified Software Development Process 1999, Pearson Education, Limited in English 0321822005 9780321822000	zzzz Nearby Libraries

Add another edition?

Book Details

Table of Contents

Preface

Page xvii

Part I. The Unified Software Development Process

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

1.1. The Unified Process in a Nutshell

1.2. The Unified Process Is Use-Case Driven

1.3. The Unified Process Is Architecture-Centric

1.4. The Unified Process Is Iterative and Incremental

1.5. The Life of the Unified Process

1.5.1. The Product

1.5.2. Phases within a Cycle

1.6. An Integrated Process

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

2.1. People Are Crucial

2.1.1. Development Processes Affect People

2.1.2. Roles Will Change

2.1.3. Turning "Resources" into "Workers"

2.2. Projects Make the Product

2.3. Product Is More Than Code

2.3.1. What Is a Software System?

2.3.2. Artifacts

2.3.3. A System Has a Collection of Models

2.3.4. What Is a Model?

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

2.3.6. Inside a Model

2.3.7. Relationships between Models

2.4. Process Directs Projects

2.4.1. Process: A Template

2.4.2. Related Activities Make Up Workflows

2.4.3. Specializing Process

2.4.4. Merits of Process

2.5. Tools Are Integral to Process

2.5.1. Tools Impact Process

2.5.2. Process Drives Tools

2.5.3. Balance Process and Tools

2.5.4. Visual Modeling Supports UML

2.5.5. Tools Support the Whole Life Cycle

2.6. References

Chapter 3. A Use-Case-Driven Process

3.1. Use-Case-Driven Development in Brief

3.2. Why Use Cases?

3.2.1. To Capture the Value Adding Requirements

3.2.2. To Drive the Process

3.2.3. To Devise the Architecture and More...

3.3. Capturing the Use Cases

3.3.1. The Use-Case Model Represents the Functional Requirements

3.3.2. Actors Are the Environment of the System

3.3.3. Use Cases Specify the System

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

3.4.1. Creating the Analysis Model from the Use Cases

3.4.2. Each Class Must Fulfill All Its Collaboration Roles

3.4.3. Creating the Design Model from the Analysis Model

3.4.4. Subsystems Group Classes

3.4.5. Creating the Implementation Model from the Design Model

3.5. Testing the Use Cases

3.6. Summing Up

3.7. References

Chapter 4. An Architecture-Centric Process

4.1. Architecture in Brief

4.2. Why We Need Architecture

4.2.1. Understanding the System

4.2.2. Organizing Development

4.2.3. Fostering Reuse

4.2.4. Evolving the System

4.3. Use Cases and Architecture

4.4. The Steps to an Architecture

4.4.1. The Architecture Baseline Is a "Small, Skinny" System

4.4.2. Using Architecture Patterns

4.4.3. Describing Architecture

4.4.4. The Architect Creates the Architecture

4.5. Finally, an Architecture Description!

4.5.1. The Architectural View of the Use-Case Model

4.5.2. The Architectural View of the Design Model

4.5.3. The Architectural View of the Deployment Model

4.5.4. The Architectural View of the Implementation Model

4.6. Three Interesting Concepts

4.6.1. What Is Architecture?

4.6.2. How Is It Obtained?

4.6.3. How Is It Described?

4.7. References

Chapter 5. An Iterative and Incremental Process

5.1. Iterative and Incremental in Brief

5.1.1. Develop in Small Steps

5.1.2. What Iteration Is Not

5.2. Why Iterative and Incremental Development?

5.2.1. Mitigating Risks

5.2.2. Getting a Robust Architecture

5.2.3. Handling Changing Requirements

5.2.4. Allowing for Tactical Changes

5.2.5. Achieving Continuous Integration

5.2.6. Attaining Early Learning

5.3. The Iterative Approach Is Risk-Driven

5.3.1. Iterations Alleviate Technical Risks

5.3.2. Management Is Responsible for Nontechnical Risks

5.3.3. Dealing with Risks

5.4. The Generic Iteration

5.4.1. What an Iteration Is

5.4.2. Planning the Iterations

5.4.3. Sequencing the Iterations

5.5. The Result of an Iteration Is an Increment

5.6. Iterations over the Life Cycle

5.7. Models Evolve from Iterations

5.8. Iterations Challenge the Organization

5.9. References

Part II. The Core Workflows

Chapter 6. Requirements Capture: From Vision to Requirements

6.1. Why Requirements Capture Is Difficult

6.2. The Purpose of the Requirements Workflow

6.3. Overview of Requirements Capture

6.4. The Role of Requirements in the Software Life Cycle

6.5. Understanding the System Context Using a Domain Model

6.5.1. What Is a Domain Model?

6.5.2. Developing a Domain Model

6.5.3. Use of the Domain Model

6.6. Understanding the System Context Using a Business Model

6.6.1. What Is a Business Model?

6.6.2. How to Develop a Business Model

6.6.3. Find Use Cases from a Business Model

6.7. Supplementary Requirements

6.9. References

Chapter 7. Capturing the Requirements as Use Cases

7.1. Introduction

7.2.1. Artifact: Use-Case Model

7.2.2. Artifact: Actor

7.2.3. Use Case

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

7.2.5. Artifact: Glossary

7.2.6. Artifact: User-Interface Prototype

7.3.1. Worker: System Analyst

7.3.2. Worker: Use-Case Specifier

7.3.3. User-Interface Designer

7.3.4. Worker: Architect

7.4.1. Activity: Find Actors and Use Cases

7.4.2. Activity: Prioritize Use Cases

7.4.3. Activity: Detail a Use Case

7.4.4. Activity: Prototype User Interface

7.4.5. Activity: Structure the Use-Case Model

7.5. Summary of the Requirements Workflow

7.6. References

Chapter 8. Analysis

8.1. Introduction

8.2. Analysis in Brief

8.2.1. Why Analysis Is not Design or Implementation

8.2.2. The Purpose of Analysis: Summary

8.2.3. Concrete Examples of When to Employ Analysis

8.3. The Role of Analysis in the Software Life Cycle

8.4.1. Artifact: Analysis Model

8.4.2. Artifact: Analysis Class

8.4.3. Artifact: Use-Case Realization—Analysis

8.4.4. Artifact: Analysis Package

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

8.5.1. Worker: Architect

8.5.2. Worker: Use-Case Engineer

8.5.3. Worker: Component Engineer

8.6.1. Activity: Architectural Analysis

8.6.2. Activity: Analyze a Use Case

8.6.3. Activity: Analyze a Class

8.6.4. Activity: Analyze a Package

8.7. Summary of Analysis

8.8. References

Chapter 9. Design

9.1. Introduction

9.2. The Role of Design in the Software Life Cycle

9.3.1. Artifact: Design Model

9.3.2. Artifact: Design Class

9.3.3. Artifact: Use-Case Realization—Design

9.3.4. Artifact: Design Subsystem

9.3.5. Artifact: Interface

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

9.3.7. Artifact: Deployment Model

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

9.4.1. Worker: Architect

9.4.2. Worker: Use-Case Engineer

9.4.3. Worker: Component Engineer

9.5.1. Activity: Architectural Design

9.5.2. Activity: Design a Use Case

9.5.3. Activity: Design a Class

9.5.4. Activity: Design a Subsystem

9.6. Summary of Design

9.7. References

Chapter 10. Implementation

10.1. Introduction

10.2. The Role of Implementation in the Software Life Cycle

10.3. Artifacts

10.3.1. Artifact: Implementation Model

10.3.2. Artifact: Component

10.3.3. Artifact: Implementation Subsystem

10.3.4. Artifact: Interface

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

10.3.6. Artifact: Integration Build Plan

10.4.1. Worker: Architect

10.4.2. Worker: Component Engineer

10.4.3. Worker: System Integrator

10.5.1. Activity: Architectural Implementation

10.5.2. Activity: Integrate System

10.5.3. Activity: Implement a Subsystem

10.5.4. Activity: Implement a Class

10.5.5. Activity: Perform Unit Test

10.6. Summary of Implementation

10.7. References

Chapter 11. Test

11.1. Introduction

11.2. The Role of Testing in the Software Life Cycle

11.3. Artifacts

11.3.1. Artifact: Test Model

11.3.2. Artifact: Test Case

11.3.3. Artifact: Test Procedure

11.3.4. Artifact: Test Component

11.3.5. Artifact: Plan Test

11.3.6. Artifact: Defect

11.3.7. Artifact: Evaluate Test

11.4.1. Worker: Test Designer

11.4.2. Worker: Component Engineer

11.4.3. Worker: Integration Tester

11.4.4. Worker: System Tester

11.5.1. Activity: Plan Test

11.5.2. Activity: Design Test

11.5.3. Activity: Implement Test

11.5.4. Activity: Perform Integration Test

11.5.5. Activity: Perform System Test

11.5.6. Activity: Evaluate Test

11.6. Summary of Testing

11.7. References

Part III. Iterative and Incremental Development

Chapter 12. The Generic Iteration Workflow

12.1. The Need for Balance

12.2. The Phases Are the First Division of Work

12.2.1. Inception Phase Establishes Feasibility

12.2.2. Elaboration Phase Focuses on "Do-Ability"

12.2.3. Construction Phase Builds the System

12.2.4. Transition Phase Moves into the User Environment

12.3. The Generic Iteration Revisited

12.3.1. Core Workflows Repeat in Each Iteration

12.3.2. Workers Participate in the Workflows

12.4. Planning Precedes Doing

12.4.1. Plan the Four Phases

12.4.2. Plan the Iterations

12.4.3. Think Long Term

12.4.4. Plan the Evaluation Criteria

12.5. Risks Affect Project Planning

12.5.1. Manage a Risk List

12.5.2. Risks Affect the Iteration Plan

12.5.3. Schedule Risk Action

12.6. Use-Case Prioritization

12.6.1. Risks Specific to a Particular Product

12.6.2. Risk of Not Getting the Architecture Right

12.6.3. Risk of Not Getting Requirements Right

12.7. Resources Needed

12.7.1. Projects Differ Widely

12.7.2. A Typical Project Looks Like This

12.7.3. Complex Projects Have Greater Needs

12.7.4. New Product Line Calls for Experience

12.7.5. Paying the Cost of the Resources Used

12.8. Assess the Iterations and Phases

12.8.1. Criteria Not Achieved

12.8.2. The Criteria Themselves

12.8.3. The Next Iteration

12.8.4. Evolution of the Model Set

Chapter 13. Inception Launches the Project

13.1. The Inception Phase in Brief

13.2. Early in the Inception Phase

13.2.1. Before the Inception Phase Begins

13.2.2. Planning the Inception Phase

13.2.3. Expanding the System Vision

13.2.4. Setting the Evaluation Criteria

13.3. The Archetypal Inception Iteration Workflow

13.3.1. Introduction to the Five Core Workflows

13.3.2. Fitting the Project into the Development Environment

13.3.3. Finding Critical Risks

13.4. Execute the Core Workflows, Requirements to Test

13.4.1. Capture the Requirements

13.4.2. Analysis

13.5. Make the Initial Business Case

13.5.1. Outline Business Bid

13.5.2. Estimate Return on Investment

13.6. Assess the Iteration(s) in the Inception Phase

13.7. Planning the Elaboration Phase

13.8. The Deliverables for the Inception Phase

Chapter 14. The Elaboration Phase Makes the Architectural Baseline

14.1. The Elaboration Phase in Brief

14.2. Early in the Elaboration Phase

14.2.1. Planning the Elaboration Phase

14.2.2. Building the Team

14.2.3. Modifying the Development Environment

14.2.4. Setting Evaluation Criteria

14.3. The Archetypal Elaboration Iteration Workflow

14.3.1. Capture and Refine Most of the Requirements

14.3.2. Develop the Architectural Baseline

14.3.3. Iterate While the Team Is Small

14.4. Execute the Core Workflows—Requirements to Test

14.4.1. Capture the Requirements

14.4.2. Analysis

14.4.4. Implementation

14.5. Make the Business Case

14.5.1. Prepare the Business Bid

14.5.2. Update Return on Investment

14.6. Assess the Iterations in the Elaboration Phase

14.7. Planning the Construction Phase

14.8. The Key Deliverables

Chapter 15. Construction Leads to Initial Operational Capability

15.1. The Construction Phase in Brief

15.2. Early in the Construction Phase

15.2.1. Staffing the Phase

15.2.2. Setting the Evaluation Criteria

15.3. The Archetypal Construction Iteration Workflow

15.4. Execute the Core Workflows—Requirements to Testing

15.4.1. Requirements

15.4.2. Analysis

15.4.4. Implementation

15.5. Controlling the Business Case

15.6. Assess the Iterations and the Construction Phase

15.7. Planning the Transition Phase

15.8. The Key Deliverables

Chapter 16. Transition Completes Product Release

16.1. The Transition Phase in Brief

16.2. Early in the Transition Phase

16.2.1. Planning the Transition Phase

16.2.2. Staffing the Transition Phase

16.2.3. Setting the Evaluation Criteria

16.3. The Core Workflows Play a Small Role in this Phase

16.4. What We Do in the Transition Phase

16.4.1. Getting the Beta Release Out

16.4.2. Installing the Beta Release

16.4.3. Responding to the Test Results

16.4.4. Adapting the Product to Varied User Environments

16.4.5. Completing the Artifacts

16.4.6. When Does the Project End?

16.5. Completing the Business Case

16.5.1. Controlling Progress

16.5.2. Review of the Business Plan

16.6. Assess the Transition Phase

16.6.1. Assess the Iterations and the Phase

16.6.2. Postmortem of the Project

16.7. Planning the Next Release or Generation

16.8. The Key Deliverables

Chapter 17. Making the Unified Process Work

17.1. The Unified Process Helps You Deal with Complexity

17.1.1. The Life Cycle Objectives

17.1.2. The Life Cycle Architecture

17.1.3. Initial Operational Capability

17.1.4. Product Release

17.2. The Major Themes

17.3. Management Leads Conversion to Unified Process

17.3.1. The Case for Action

17.3.2. The Reengineering Directive Persuades

17.3.3. Implementing the Transition

17.4. Specializing the Unified Process

17.4.1. Tailoring the Process

17.4.2. Filling in the Process Framework

17.5. Relate to the Broader Community

17.6. Get the Benefits of the Unified Process

17.7. References

Appendix A. Overview of the UML

A.1. Introduction

A.1.1. Vocabulary

A.1.2. Extensibility Mechanisms

A.2. Graphical Notation

A.2.1. Structural Things

A.2.2. Behavioral Things

A.2.3. Grouping Things

A.2.4. Annotational Things

A.2.5. Dependency Relationships

A.2.6. Association Relationships

A.2.7. Generalization Relationships

A.2.8. Extensibility Mechanisms

A.3. Glossary of Terms

A.4. References

Appendix B. The Unified Process–Specific Extensions of the UML

B.1. Introduction

B.2. Stereotypes

B.3. Tagged Values

B.4. Graphical Notation

B.5. References

Appendix C. General Glossary

C.1. Introduction

Edition Notes

Includes bibliographical references and index.

Published in: Reading, Mass
Series: The Addison-Wesley object technology series

Classifications

Dewey Decimal Class: 005.1
Library of Congress: QA76.76.D47 J35 1999, QA76.76.D47.J35 1999

The Physical Object

Pagination: xxix, 463 p. :
Number of pages: 463

Edition Identifiers

Open Library: OL375386M
ISBN 10: 0201571692
LCCN: 98037256
OCLC/WorldCat: 39765324
LibraryThing: 16839
Goodreads: 1469762

Work Identifiers

Work ID: OL1953420W

Source records

Community Reviews (0)

No community reviews have been submitted for this work.

Lists

Loading indicator — Loading carousel

Download catalog record: RDF / JSON