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