An edition of The unified software development process (1999)

The unified software development process

by

  • 11 Want to read
Cover of: The unified software development process by Ivar Jacobson, Ivar Jacobson
Preview Only

My Reading Lists:

Create a new list
Notes
  • 11 Want to read
Notes

Check nearby libraries

Buy this book

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

  • 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
Publisher
Addison-Wesley
Language
English
Pages
463

Check nearby libraries

Buy this book

Previews available in: English

Subjects

Development, UML (Computer science), Computer software, Object-oriented methods (computer science), Computer software, development, Computer software--development, Qa76.76.d47 j35 1999, 005.1
Edition Availability
Cover of: Le Processus unifié de développement logiciel
Le Processus unifié de développement logiciel
June 23, 2000, Eyrolles
Paperback in French
Cover of: El Proceso Unificado de Desarrollo de Software
El Proceso Unificado de Desarrollo de Software
November 2000, Addison Wesley Publishing Company, ADDISON WESLEY
Paperback
Cover of: The unified software development process
The unified software development process
1999, Addison-Wesley
in English
Cover of: Unified Software Development Process
Unified Software Development Process
1999, Pearson Education, Limited
in English

Add another edition?

Book Details

Table of Contents

Preface
Page xvii
Part I. The Unified Software Development Process
Page 1
Chapter 1. The Unified Process: Use-Case Driven, Architecture-Centric, Iterative, and Incremental
Page 3
1.1. The Unified Process in a Nutshell
Page 4
1.2. The Unified Process Is Use-Case Driven
Page 5
1.3. The Unified Process Is Architecture-Centric
Page 6
1.4. The Unified Process Is Iterative and Incremental
Page 7
1.5. The Life of the Unified Process
Page 8
1.5.1. The Product
Page 9
1.5.2. Phases within a Cycle
Page 11
1.6. An Integrated Process
Page 13
Chapter 2. The Four Ps: People, Project, Product, and Process in Software Development
Page 15
2.1. People Are Crucial
Page 16
2.1.1. Development Processes Affect People
Page 16
2.1.2. Roles Will Change
Page 17
2.1.3. Turning "Resources" into "Workers"
Page 18
2.2. Projects Make the Product
Page 19
2.3. Product Is More Than Code
Page 20
2.3.1. What Is a Software System?
Page 20
2.3.2. Artifacts
Page 21
2.3.3. A System Has a Collection of Models
Page 21
2.3.4. What Is a Model?
Page 22
2.3.5. Each Model Is a Self-Contained View of the System
Page 22
2.3.6. Inside a Model
Page 23
2.3.7. Relationships between Models
Page 23
2.4. Process Directs Projects
Page 24
2.4.1. Process: A Template
Page 24
2.4.2. Related Activities Make Up Workflows
Page 25
2.4.3. Specializing Process
Page 26
2.4.4. Merits of Process
Page 27
2.5. Tools Are Integral to Process
Page 28
2.5.1. Tools Impact Process
Page 28
2.5.2. Process Drives Tools
Page 28
2.5.3. Balance Process and Tools
Page 29
2.5.4. Visual Modeling Supports UML
Page 29
2.5.5. Tools Support the Whole Life Cycle
Page 30
2.6. References
Page 31
Chapter 3. A Use-Case-Driven Process
Page 33
3.1. Use-Case-Driven Development in Brief
Page 35
3.2. Why Use Cases?
Page 37
3.2.1. To Capture the Value Adding Requirements
Page 37
3.2.2. To Drive the Process
Page 38
3.2.3. To Devise the Architecture and More...
Page 39
3.3. Capturing the Use Cases
Page 40
3.3.1. The Use-Case Model Represents the Functional Requirements
Page 40
3.3.2. Actors Are the Environment of the System
Page 41
3.3.3. Use Cases Specify the System
Page 41
3.4. Analysis, Design, and Implementation to Realize the Use Cases
Page 42
3.4.1. Creating the Analysis Model from the Use Cases
Page 43
3.4.2. Each Class Must Fulfill All Its Collaboration Roles
Page 48
3.4.3. Creating the Design Model from the Analysis Model
Page 48
3.4.4. Subsystems Group Classes
Page 51
3.4.5. Creating the Implementation Model from the Design Model
Page 53
3.5. Testing the Use Cases
Page 55
3.6. Summing Up
Page 57
3.7. References
Page 57
Chapter 4. An Architecture-Centric Process
Page 59
4.1. Architecture in Brief
Page 60
4.2. Why We Need Architecture
Page 62
4.2.1. Understanding the System
Page 62
4.2.2. Organizing Development
Page 63
4.2.3. Fostering Reuse
Page 63
4.2.4. Evolving the System
Page 64
4.3. Use Cases and Architecture
Page 65
4.4. The Steps to an Architecture
Page 69
4.4.1. The Architecture Baseline Is a "Small, Skinny" System
Page 69
4.4.2. Using Architecture Patterns
Page 71
4.4.3. Describing Architecture
Page 74
4.4.4. The Architect Creates the Architecture
Page 76
4.5. Finally, an Architecture Description!
Page 77
4.5.1. The Architectural View of the Use-Case Model
Page 78
4.5.2. The Architectural View of the Design Model
Page 78
4.5.3. The Architectural View of the Deployment Model
Page 81
4.5.4. The Architectural View of the Implementation Model
Page 83
4.6. Three Interesting Concepts
Page 83
4.6.1. What Is Architecture?
Page 83
4.6.2. How Is It Obtained?
Page 83
4.6.3. How Is It Described?
Page 83
4.7. References
Page 84
Chapter 5. An Iterative and Incremental Process
Page 85
5.1. Iterative and Incremental in Brief
Page 86
5.1.1. Develop in Small Steps
Page 87
5.1.2. What Iteration Is Not
Page 88
5.2. Why Iterative and Incremental Development?
Page 89
5.2.1. Mitigating Risks
Page 89
5.2.2. Getting a Robust Architecture
Page 91
5.2.3. Handling Changing Requirements
Page 91
5.2.4. Allowing for Tactical Changes
Page 92
5.2.5. Achieving Continuous Integration
Page 92
5.2.6. Attaining Early Learning
Page 93
5.3. The Iterative Approach Is Risk-Driven
Page 94
5.3.1. Iterations Alleviate Technical Risks
Page 95
5.3.2. Management Is Responsible for Nontechnical Risks
Page 97
5.3.3. Dealing with Risks
Page 97
5.4. The Generic Iteration
Page 98
5.4.1. What an Iteration Is
Page 98
5.4.2. Planning the Iterations
Page 100
5.4.3. Sequencing the Iterations
Page 100
5.5. The Result of an Iteration Is an Increment
Page 101
5.6. Iterations over the Life Cycle
Page 102
5.7. Models Evolve from Iterations
Page 105
5.8. Iterations Challenge the Organization
Page 106
5.9. References
Page 106
Part II. The Core Workflows
Page 109
Chapter 6. Requirements Capture: From Vision to Requirements
Page 111
6.1. Why Requirements Capture Is Difficult
Page 112
6.2. The Purpose of the Requirements Workflow
Page 113
6.3. Overview of Requirements Capture
Page 113
6.4. The Role of Requirements in the Software Life Cycle
Page 118
6.5. Understanding the System Context Using a Domain Model
Page 119
6.5.1. What Is a Domain Model?
Page 119
6.5.2. Developing a Domain Model
Page 121
6.5.3. Use of the Domain Model
Page 121
6.6. Understanding the System Context Using a Business Model
Page 122
6.6.1. What Is a Business Model?
Page 122
6.6.2. How to Develop a Business Model
Page 124
6.6.3. Find Use Cases from a Business Model
Page 126
6.7. Supplementary Requirements
Page 128
6.8. Summary
Page 130
6.9. References
Page 130
Chapter 7. Capturing the Requirements as Use Cases
Page 131
7.1. Introduction
Page 131
7.2. Artifacts
Page 133
7.2.1. Artifact: Use-Case Model
Page 133
7.2.2. Artifact: Actor
Page 134
7.2.3. Use Case
Page 135
7.2.4. Artifact: Architecture Description (View of the Use-Case Model)
Page 139
7.2.5. Artifact: Glossary
Page 139
7.2.6. Artifact: User-Interface Prototype
Page 140
7.3. Workers
Page 140
7.3.1. Worker: System Analyst
Page 140
7.3.2. Worker: Use-Case Specifier
Page 141
7.3.3. User-Interface Designer
Page 142
7.3.4. Worker: Architect
Page 142
7.4. Workflow
Page 143
7.4.1. Activity: Find Actors and Use Cases
Page 144
7.4.2. Activity: Prioritize Use Cases
Page 153
7.4.3. Activity: Detail a Use Case
Page 153
7.4.4. Activity: Prototype User Interface
Page 160
7.4.5. Activity: Structure the Use-Case Model
Page 166
7.5. Summary of the Requirements Workflow
Page 171
7.6. References
Page 172
Chapter 8. Analysis
Page 173
8.1. Introduction
Page 173
8.2. Analysis in Brief
Page 176
8.2.1. Why Analysis Is not Design or Implementation
Page 176
8.2.2. The Purpose of Analysis: Summary
Page 177
8.2.3. Concrete Examples of When to Employ Analysis
Page 178
8.3. The Role of Analysis in the Software Life Cycle
Page 179
8.4. Artifacts
Page 181
8.4.1. Artifact: Analysis Model
Page 181
8.4.2. Artifact: Analysis Class
Page 181
8.4.3. Artifact: Use-Case Realization—Analysis
Page 186
8.4.4. Artifact: Analysis Package
Page 190
8.4.5. Artifact: Architecture Description (View of the Analysis Model)
Page 193
8.5. Workers
Page 194
8.5.1. Worker: Architect
Page 194
8.5.2. Worker: Use-Case Engineer
Page 194
8.5.3. Worker: Component Engineer
Page 195
8.6. Workflow
Page 196
8.6.1. Activity: Architectural Analysis
Page 196
8.6.2. Activity: Analyze a Use Case
Page 203
8.6.3. Activity: Analyze a Class
Page 207
8.6.4. Activity: Analyze a Package
Page 211
8.7. Summary of Analysis
Page 213
8.8. References
Page 214
Chapter 9. Design
Page 215
9.1. Introduction
Page 215
9.2. The Role of Design in the Software Life Cycle
Page 216
9.3. Artifacts
Page 217
9.3.1. Artifact: Design Model
Page 217
9.3.2. Artifact: Design Class
Page 218
9.3.3. Artifact: Use-Case Realization—Design
Page 221
9.3.4. Artifact: Design Subsystem
Page 224
9.3.5. Artifact: Interface
Page 226
9.3.6. Artifact: Architecture Description (View of the Design Model)
Page 226
9.3.7. Artifact: Deployment Model
Page 227
9.3.8. Artifact: Architecture Description (View of the Deployment Model)
Page 228
9.4. Workers
Page 229
9.4.1. Worker: Architect
Page 229
9.4.2. Worker: Use-Case Engineer
Page 230
9.4.3. Worker: Component Engineer
Page 230
9.5. Workflow
Page 231
9.5.1. Activity: Architectural Design
Page 232
9.5.2. Activity: Design a Use Case
Page 249
9.5.3. Activity: Design a Class
Page 255
9.5.4. Activity: Design a Subsystem
Page 263
9.6. Summary of Design
Page 265
9.7. References
Page 266
Chapter 10. Implementation
Page 267
10.1. Introduction
Page 267
10.2. The Role of Implementation in the Software Life Cycle
Page 268
10.3. Artifacts
Page 269
10.3.1. Artifact: Implementation Model
Page 269
10.3.2. Artifact: Component
Page 269
10.3.3. Artifact: Implementation Subsystem
Page 272
10.3.4. Artifact: Interface
Page 274
10.3.5. Artifact: Architecture Description (View of the Implementation Model)
Page 275
10.3.6. Artifact: Integration Build Plan
Page 276
10.4. Workers
Page 277
10.4.1. Worker: Architect
Page 277
10.4.2. Worker: Component Engineer
Page 277
10.4.3. Worker: System Integrator
Page 279
10.5. Workflow
Page 279
10.5.1. Activity: Architectural Implementation
Page 280
10.5.2. Activity: Integrate System
Page 283
10.5.3. Activity: Implement a Subsystem
Page 285
10.5.4. Activity: Implement a Class
Page 288
10.5.5. Activity: Perform Unit Test
Page 289
10.6. Summary of Implementation
Page 293
10.7. References
Page 293
Chapter 11. Test
Page 295
11.1. Introduction
Page 295
11.2. The Role of Testing in the Software Life Cycle
Page 296
11.3. Artifacts
Page 297
11.3.1. Artifact: Test Model
Page 297
11.3.2. Artifact: Test Case
Page 297
11.3.3. Artifact: Test Procedure
Page 300
11.3.4. Artifact: Test Component
Page 302
11.3.5. Artifact: Plan Test
Page 302
11.3.6. Artifact: Defect
Page 302
11.3.7. Artifact: Evaluate Test
Page 302
11.4. Workers
Page 303
11.4.1. Worker: Test Designer
Page 303
11.4.2. Worker: Component Engineer
Page 303
11.4.3. Worker: Integration Tester
Page 303
11.4.4. Worker: System Tester
Page 304
11.5. Workflow
Page 304
11.5.1. Activity: Plan Test
Page 305
11.5.2. Activity: Design Test
Page 306
11.5.3. Activity: Implement Test
Page 309
11.5.4. Activity: Perform Integration Test
Page 310
11.5.5. Activity: Perform System Test
Page 311
11.5.6. Activity: Evaluate Test
Page 311
11.6. Summary of Testing
Page 313
11.7. References
Page 313
Part III. Iterative and Incremental Development
Page 315
Chapter 12. The Generic Iteration Workflow
Page 317
12.1. The Need for Balance
Page 318
12.2. The Phases Are the First Division of Work
Page 319
12.2.1. Inception Phase Establishes Feasibility
Page 319
12.2.2. Elaboration Phase Focuses on "Do-Ability"
Page 320
12.2.3. Construction Phase Builds the System
Page 321
12.2.4. Transition Phase Moves into the User Environment
Page 322
12.3. The Generic Iteration Revisited
Page 322
12.3.1. Core Workflows Repeat in Each Iteration
Page 322
12.3.2. Workers Participate in the Workflows
Page 323
12.4. Planning Precedes Doing
Page 324
12.4.1. Plan the Four Phases
Page 325
12.4.2. Plan the Iterations
Page 326
12.4.3. Think Long Term
Page 327
12.4.4. Plan the Evaluation Criteria
Page 327
12.5. Risks Affect Project Planning
Page 328
12.5.1. Manage a Risk List
Page 328
12.5.2. Risks Affect the Iteration Plan
Page 329
12.5.3. Schedule Risk Action
Page 329
12.6. Use-Case Prioritization
Page 330
12.6.1. Risks Specific to a Particular Product
Page 331
12.6.2. Risk of Not Getting the Architecture Right
Page 331
12.6.3. Risk of Not Getting Requirements Right
Page 332
12.7. Resources Needed
Page 333
12.7.1. Projects Differ Widely
Page 334
12.7.2. A Typical Project Looks Like This
Page 335
12.7.3. Complex Projects Have Greater Needs
Page 335
12.7.4. New Product Line Calls for Experience
Page 336
12.7.5. Paying the Cost of the Resources Used
Page 337
12.8. Assess the Iterations and Phases
Page 338
12.8.1. Criteria Not Achieved
Page 338
12.8.2. The Criteria Themselves
Page 339
12.8.3. The Next Iteration
Page 339
12.8.4. Evolution of the Model Set
Page 340
Chapter 13. Inception Launches the Project
Page 341
13.1. The Inception Phase in Brief
Page 341
13.2. Early in the Inception Phase
Page 342
13.2.1. Before the Inception Phase Begins
Page 342
13.2.2. Planning the Inception Phase
Page 343
13.2.3. Expanding the System Vision
Page 344
13.2.4. Setting the Evaluation Criteria
Page 344
13.3. The Archetypal Inception Iteration Workflow
Page 346
13.3.1. Introduction to the Five Core Workflows
Page 346
13.3.2. Fitting the Project into the Development Environment
Page 348
13.3.3. Finding Critical Risks
Page 348
13.4. Execute the Core Workflows, Requirements to Test
Page 348
13.4.1. Capture the Requirements
Page 350
13.4.2. Analysis
Page 352
13.4.3. Design
Page 353
13.4.5. Test
Page 354
13.5. Make the Initial Business Case
Page 354
13.5.1. Outline Business Bid
Page 354
13.5.2. Estimate Return on Investment
Page 356
13.6. Assess the Iteration(s) in the Inception Phase
Page 356
13.7. Planning the Elaboration Phase
Page 357
13.8. The Deliverables for the Inception Phase
Page 358
Chapter 14. The Elaboration Phase Makes the Architectural Baseline
Page 359
14.1. The Elaboration Phase in Brief
Page 359
14.2. Early in the Elaboration Phase
Page 360
14.2.1. Planning the Elaboration Phase
Page 360
14.2.2. Building the Team
Page 361
14.2.3. Modifying the Development Environment
Page 361
14.2.4. Setting Evaluation Criteria
Page 361
14.3. The Archetypal Elaboration Iteration Workflow
Page 362
14.3.1. Capture and Refine Most of the Requirements
Page 363
14.3.2. Develop the Architectural Baseline
Page 364
14.3.3. Iterate While the Team Is Small
Page 364
14.4. Execute the Core Workflows—Requirements to Test
Page 364
14.4.1. Capture the Requirements
Page 365
14.4.2. Analysis
Page 367
14.4.3. Design
Page 372
14.4.4. Implementation
Page 374
14.4.5. Test
Page 376
14.5. Make the Business Case
Page 377
14.5.1. Prepare the Business Bid
Page 378
14.5.2. Update Return on Investment
Page 378
14.6. Assess the Iterations in the Elaboration Phase
Page 378
14.7. Planning the Construction Phase
Page 379
14.8. The Key Deliverables
Page 380
Chapter 15. Construction Leads to Initial Operational Capability
Page 381
15.1. The Construction Phase in Brief
Page 382
15.2. Early in the Construction Phase
Page 382
15.2.1. Staffing the Phase
Page 383
15.2.2. Setting the Evaluation Criteria
Page 383
15.3. The Archetypal Construction Iteration Workflow
Page 384
15.4. Execute the Core Workflows—Requirements to Testing
Page 385
15.4.1. Requirements
Page 387
15.4.2. Analysis
Page 388
15.4.3. Design
Page 389
15.4.4. Implementation
Page 390
15.4.5. Test
Page 391
15.5. Controlling the Business Case
Page 393
15.6. Assess the Iterations and the Construction Phase
Page 393
15.7. Planning the Transition Phase
Page 393
15.8. The Key Deliverables
Page 394
Chapter 16. Transition Completes Product Release
Page 395
16.1. The Transition Phase in Brief
Page 396
16.2. Early in the Transition Phase
Page 397
16.2.1. Planning the Transition Phase
Page 397
16.2.2. Staffing the Transition Phase
Page 399
16.2.3. Setting the Evaluation Criteria
Page 399
16.3. The Core Workflows Play a Small Role in this Phase
Page 400
16.4. What We Do in the Transition Phase
Page 401
16.4.1. Getting the Beta Release Out
Page 401
16.4.2. Installing the Beta Release
Page 402
16.4.3. Responding to the Test Results
Page 402
16.4.4. Adapting the Product to Varied User Environments
Page 403
16.4.5. Completing the Artifacts
Page 404
16.4.6. When Does the Project End?
Page 404
16.5. Completing the Business Case
Page 405
16.5.1. Controlling Progress
Page 405
16.5.2. Review of the Business Plan
Page 405
16.6. Assess the Transition Phase
Page 406
16.6.1. Assess the Iterations and the Phase
Page 406
16.6.2. Postmortem of the Project
Page 407
16.7. Planning the Next Release or Generation
Page 407
16.8. The Key Deliverables
Page 407
Chapter 17. Making the Unified Process Work
Page 409
17.1. The Unified Process Helps You Deal with Complexity
Page 409
17.1.1. The Life Cycle Objectives
Page 410
17.1.2. The Life Cycle Architecture
Page 410
17.1.3. Initial Operational Capability
Page 411
17.1.4. Product Release
Page 411
17.2. The Major Themes
Page 411
17.3. Management Leads Conversion to Unified Process
Page 412
17.3.1. The Case for Action
Page 413
17.3.2. The Reengineering Directive Persuades
Page 413
17.3.3. Implementing the Transition
Page 414
17.4. Specializing the Unified Process
Page 416
17.4.1. Tailoring the Process
Page 416
17.4.2. Filling in the Process Framework
Page 417
17.5. Relate to the Broader Community
Page 418
17.6. Get the Benefits of the Unified Process
Page 418
17.7. References
Page 419
Appendix A. Overview of the UML
Page 421
A.1. Introduction
Page 421
A.1.1. Vocabulary
Page 422
A.1.2. Extensibility Mechanisms
Page 422
A.2. Graphical Notation
Page 423
A.2.1. Structural Things
Page 423
A.2.2. Behavioral Things
Page 424
A.2.3. Grouping Things
Page 425
A.2.4. Annotational Things
Page 425
A.2.5. Dependency Relationships
Page 425
A.2.6. Association Relationships
Page 425
A.2.7. Generalization Relationships
Page 426
A.2.8. Extensibility Mechanisms
Page 426
A.3. Glossary of Terms
Page 426
A.4. References
Page 433
Appendix B. The Unified Process–Specific Extensions of the UML
Page 435
B.1. Introduction
Page 435
B.2. Stereotypes
Page 435
B.3. Tagged Values
Page 438
B.4. Graphical Notation
Page 439
B.5. References
Page 439
Appendix C. General Glossary
Page 441
C.1. Introduction
Page 441
C.2. Terms
Page 441
Index
Page 451

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

Scriblio MARC record
Ithaca College Library MARC record
amazon.com record
Better World Books record
Library of Congress MARC record
Internet Archive item record
ISBNdb
Harvard University record

Community Reviews (0)

No community reviews have been submitted for this work.

Lists

Loading indicator
Loading carousel
Loading indicator
Loading carousel

History

Download catalog record: RDF / JSON
July 22, 2025 Edited by MARC Bot import existing book
December 4, 2024 Edited by Tom Morris Merge works
December 19, 2023 Edited by ImportBot import existing book
October 5, 2021 Edited by ImportBot import existing book
December 9, 2009 Created by WorkBot add works page