8/12/2019 ooad sylabus

1/12

The UnifiedSoftware DevelopmentProcessIvar JacobsonGrady BoochJames RumbaughRational Software orporation

Technieche U niv er sa l DarmstadtFACHBEREICH IN-FORMAHKB L I O T H E K

tnventar-NSr.:Sachgebiete:Siandort:

TADDISON-WESLEYAn Imprint of Addison Wesley Longm an, Inc.Reading,Massachusetts Harlow, England Menlo Park, CaliforniaBerkeley, California Don M ills, Ontario SydneyBonn Amsterdam Tokyo M exico City

8/12/2019 ooad sylabus

2/12

ont nts

Preface xviiPart I: The Unified Software Developm ent Process 1Chapter 1:The Unified Process: Use -Case Driven,Arch itecture-Centric, Iterative, and Incremental 3

1.1 The Unified Process in a Nutshell 41.2 The Unified Process Is Use -Case Driven 51.3 The Unified Process Is Architecture-Cen tric 61.4 The Unified Process Is Iterative and Incremental1.5 The Life of the Unified Process 81.5.1 The Product 91.5.2 Phases within a Cycle 111.6 An Integrated Process 13

8/12/2019 ooad sylabus

3/12

vi Contents

Chapter2:The Four Ps: People, Project, Product,and Process in Software Development 152.1 People Are Crucial 162.1.1 Developmen t Processes Affect People 162.1.2 Roles W ill Chang e 172.1.3 Turning Re sources into W orkers 182.2 Projects M ake the Product 192.3 Product Is More Than Code 202.3.1 What Is a Software System? 202.3.2 Artifacts 212.3.3 A System Has a Collection of Models 212.3.4 What Is a Mode l? 222.3.5 Each Mod el Is a Se lf-Contained View of the System 222.3.6 Inside a Mo del 232.3.7 Relationships between Mo dels 232.4 Process Directs Projects 242.4.1 Process: A Template 242.4.2 Related Activities Make Up Wo rkflows 252.4.3 Spec ializing Process 262.4.4 Me rits of Process 272.5 Tools Are Integral to Process 282.5.1 Tools Impact Process 282.5.2 Process Drives Tools 282.5.3 Balance Process and Tools 29

2.5.4 Visual Mod eling Sup ports UM L 292.5.5 Tools Supp ort the Whole Life Cycle 302.6 References 31Chapter 3: A Use-Case-Driven Process 33

3.1 Use -Case-D riven Development in Brief 353.2 Why Use Cases? 373.2.1 To Capture the Value Ad ding Requirements 373.2.2 To Drive the Process 383.2.3 To Devise the Arch itecture and M ore ... 393.3 Capturing the Use Cases 403.3.1 The Use-Case Mo del Represents the FunctionalRequirements 403.3.2 Actors Are the Environment of the System 413.3.3 Use Cases Specify the System 413.4 Analysis, Design, and Implementation to Realize the Use Cases 423.4.1 Creating the Analysis Mo del from the Use Cases 433.4.2 Each Class Must Fulfill All Its Collabo ration Roles 48

8/12/2019 ooad sylabus

4/12

Contents vii

3.4.3 Creating the Design Model from the Analysis Mod el 483.4.4 Subsystems Group Classes 513.4.5 Creating the Implem entation Model from the Design Model 533.5 Testing the Use Cases 553.6 Summing Up 573.7 References 57

Chapter4:An Arch itecture-Centric Process 594.1 Architecture in Brief 604.2 Why We Need Architecture 624.2.1 Understanding the System 624.2.2 Organizing Developm ent 634.2.3 Fostering Reuse 63

4.2.4 Evolving the System 644.3 Use Cases and Architecture 654.4 The Steps to an Architecture 694.4.1 The Arch itecture Baseline Is a Sm all, Skinn y System 694.4.2 Using Arch itecture Patterns 714.4.3 Describing Arch itecture 744.4.4 The Architect Creates the Arch itecture 764.5 Finally, an Architecture Desc ription 774.5.1 The Architectural View of the Use-Case Mod el 784.5.2 The Arch itectural View of the Design Mo del 784.5.3 The Architectural View of the Deployment Mo del 814.5.4 The Architectural View of the Implementation Model 834.6 Three Interesting Conce pts 834.6.1 W hat Is Architecture? 834.6.2 How Is It Ob tained? 834.6.3 How Is It Described? 834.7 References 84

Chapter 5: An Iterative and Incremental Process 855.1 Iterative and Incremental in Brief 865.1.1 Develop in Sma ll Steps 875.1.2 What Iteration Is Not 885.2 Why Iterative and Incremental Development? 895.2.1 Mitigating Risks 895.2.2 Ge tting a Robust Arch itecture 915.2.3 Handling Chan ging Requirements 915.2.4 Allowing for Tactical Changes 925.2.5 Achieving Con tinuous Integration 925.2.6 Attaining Early Learning 93

8/12/2019 ooad sylabus

5/12

viii Contents

5.3 The Iterative Approach is Risk-Driven 945.3.1 Iterations Alleviate Technical Risks 955.3.2 Man agem ent Is Resp onsible for Non technical Risks 975.3.3 Dealing with Risks 975.4 The Generic Iteration 985.4.1 What an Iteration Is 985.4.2 Planning the Iterations 1005.4.3 Seq uencing the Iterations 1005.5 The Result of an Iteration Is an Increm ent 1015.6 Iterations over the Life Cycle 1025.7 Models Evolve from Iterations 1055.8 Iterations Challenge the Organization 1065.9 References 106

Part II:The Core Workflows 109Chapter 6: Requirements Cap ture: From Vision to Requirements 111

6.1 Wh y Requirements Cap ture Is Difficult 1126.2 The Purpose of the Requirements Workflow 1136.3 Overview of Requirements Capture 1136.4 The Role of Requ irements in the Software Life Cycle 1186.5 Understanding the System Context Using a Dom ain Mo del 1196.5.1 What Is a Domain Model? 1196.5.2 Developing a Dom ain Mod el 1216.5.3 Use of the Dom ain Mo del 1216.6 Understanding the System Context Using a Business Mod el 1226.6.1 W hat Is a Business Mo del? 1226.6.2 How to Develop a Business Mod el 1246.6.3 Find Use Cases from a Business Mo del 1266.7 Supp lementary Requirements 1286.8 Summ ary 1306.9 References 130

Chapter 7: Capturing the Requirements as Use Cases 1317.1 Introduction 1317.2 Artifacts 1337.2.1 Artifact: Use-Case Mod el 1337.2.2 Artifac t: Ac tor 1347.2.3 Use Case 1357.2.4 Artifac t: Arch itecture Desc ription (View of theUse-Case Model) 139

8/12/2019 ooad sylabus

6/12

Contents ix

7.2.5 Artifact: Glossary 1397.2.6 Artifact: User-Interface Prototype 1407.3 Workers 1407.3.1 Worker: System Analyst 1407.3.2 Worker: Use-Case Specifier 1417.3.3 User-Interface Designer 1427.3.4 Worker: Architect 1427.4 Workflow 1437.4.1 Activity: Find Actorsand UseCases 1447.4.2 Activity: PrioritizeUseCases 1537.4.3 Activity: Detaila UseCase 1537.4.4 Activity: Prototype User Interface 1607.4.5 Activity: StructuretheUse-Case Model 1667.5 Summaryof theRequirements Workflow 171

7.6 References 172Chapter 8: Analysis 173 \ fl \

8.1 Introduction 173 uaX8.2 AnalysisinBrief 176 ^ rs^ ^8.2.1 Why AnalysisIs notDesignorImplementation 1768.2.2 ThePurposeofAnalysis: Summary 1778.2.3 Concrete ExamplesofWhentoEmploy Analysis 1788.3 TheRoleofAnalysisin theSoftware Life Cycle 1798.4 Artifacts 1818.4.1 Artifact: Analysis Model 1818.4.2 Artifact: Analysis Class 1818.4.3 Artifact: Use-Case RealizationAnalysis 1868.4.4 Artifact: Analysis Package 1908.4.5 Artifact: Architecture Description Viewof theAnalysis Model) 1938.5 Workers 1948.5.1 Worker: Architect 1948.5.2 Worker: Use-Case Engineer 194

8.5.3 Worker: Component Engineer 1958.6 Workflow 1968.6.1 Activity: Architectural Analysis 1968.6.2 Activity: Analyzea UseCase 2038.6.3 Activity: AnalyzeaClass 2078.6.4 Activity: AnalyzeaPackage 2118.7 SummaryofAnalysis 2138.8 References 214

8/12/2019 ooad sylabus

7/12

Contents

Chapter9:Design 215> 9.1 Introduction 2159.2 The Role of Design in the Software Life Cycle 2169.3 Artifacts 2179.3.1 Artifact: Design Model 2179.3.2 Artifac t: Design Class 2189.3.3 Artifac t: Use-Case Realization Design 2219.3.4 Artifact: Design Subsystem 2249.3.5 Artifac t: Interface 22 69.3.6 Artifact: Architecture Description (View of the Design Model) 2269.3.7 Artifac t: Deploym ent Mod el 2279.3.8 Artifac t: Arch itecture Description (View of theDeploym ent Model) 22 89.4 Workers 2299.4.1 Worker: Arch itect 2299.4.2 Worker: Use-Ca se Engineer 2309.4.3 Worker: Com ponen t Engineer 2309.5 Wo rkflow 2319.5.1 Ac tivity: Arch itectural Design 2329.5.2 Activity: Design a Use Case 2499.5.3 Ac tivity: Design a Class 2559.5.4 Activity: Design a Subsystem 2639.6 Summ ary of Design 2659.7 References 266Chapter10:Implementation 267

10.1 Introduction 26710.2 The Role of Implem entation in the Software Life Cycle 26810.3 Artifacts 26910.3.1 Artifact: Implem entation Mo del 26910.3.2 Artifact: Com ponent 26910.3.3 Artifact: Implementation Subsystem 27210.3.4 Artifact: Interface 27410.3.5 Artifact: Arch itecture Description (View of theImplem entation Model) 27510.3.6 Artifac t: Integration Build Plan 27610.4 Wo rkers 27710.4.1 Worker: Architect 27710.4.2 W orker: Com pone nt Engineer 27710.4.3 Worker: System Integrator 27910.5 Wo rkflow 27910.5.1 Ac tivity: Architectural Implementation 28010.5.2 A ctivity: Integrate System 283

8/12/2019 ooad sylabus

8/12

Contents xi

10.5.3 Activity: Implement a Subsystem 28510.5.4 Activity: Implement a Class 28810.5.5 Ac tivity: Perform Unit Test 28910.6 Sum mary of Impleme ntation 29310.7 References 293

Chapter 11:Test 29511.1 Introduction 29511.2 The Role of Testing in the Software Life Cycle 29611.3 Artifacts 29711.3.1 Artifact: Test Model 29711.3.2 Artifact: Test Case 29711.3.3 Artifact: Test Procedure 300

11.3.4 Artifact: Test Com ponent 30211.3.5 A rtifact: Plan Test 30211.3.6 Artifact: Defect 30211.3.7 Artifact: Evaluate Test 30211.4 Wo rkers 30311.4.1. Worker: Test Designer 30311.4.2 W orker: Com pone nt Engineer 30311.4.3 W orker: Integration Tester 30311.4.4 Worker: System Tester 30411.5 Wo rkflow 30411.5.1 A ctivity: Plan Test 30511.5.2 Activity: Design Test 30611.5.3 Activity: Implement Test 30911.5.4 Activity: Perform Integration Test 31011.5.5 Activity: Perform System Test 31111.5.6 Activity: Evaluate Test 31111.6 Sum mary of Testing 31311.7 References 313

PartIII:Iterative and Incremental Development 315Chapter 12:The Generic Iteration Workflow 31712.1 The Need for Balance 31812.2 The Phases Are the First Division of Work 31912.2.1. Inception Phase Establishes Feasibility 31912.2.2 Elaboration Phase Focuses on Do-A bility 32012.2.3 Con struction Phase Builds the System 32112.2.4 Transition Phase Moves into the User Environment 322

8/12/2019 ooad sylabus

9/12

xii Contents

12.3 The Generic Iteration Revisited 32212.3.1 Core W orkflows Repeat in Each Iteration 32212.3.2 Workers Participate in the W orkflows 32312.4 Planning Precedes Doing 32412.4.1 Plan the Four Phases 32512.4.2 Plan the Iterations 32612.4.3 Think Long Term 32712.4.4 Plan the Evaluation Criteria 32712.5 Risks Affect Project Planning 32 812.5.1 Manage a Risk List 32812.5.2 Risks Affect the Iteration Plan 32912.5.3 Sche dule Risk Ac tion 32912.6 Use -Case Prioritization 33012.6.1 Risks Spe cific to a Particular Produc t 33112.6.2 Risk of Not Ge tting the Arch itecture Right 33112.6.3 Risk of Not Ge tting Requirements Right 33212.7 Resources Need ed 33312.7.1 Projects Differ W idely 33412.7.2 A Typical Project Looks Like This 33512.7.3 Com plex Projects Have Greater Needs 33512.7.4 New Produ ct Line Calls for Experience 33612.7.5 Paying the Cost of the Resources Used 33712.8 Assess the Iterations and Phases 33812.8.1 C riteria Not Ach ieved 33812.8.2 The Criteria Themselves 33912.8.3 The Next Iteration 339N 12.8.4 Evolution of the Mo del Set 340

Cha pter 13: Inception Launches the Project 34113.1 The Inception Phase in Brief 34113.2 Early in the Inception Phase 34213.2.1 Before the Inception Phase Begins 34213.2.2 Planning the Inception Phase 343

13.2.3 Expand ing the System Vision 34413.2.4 Setting the Evaluation Criteria 34413.3 The Archetypal Inception Iteration Wo rkflow 34613.3.1 Introduc tion to the Five Core Wo rkflows 34613.3.2 Fitting the Project into the Developm ent Environment 34813.3.3 F inding Critical Risks 34813.4 Execute the Core Wo rkflows, Requirements to Test 34813.4.1 Cap ture the Requirements 35013.4.2 Analysis 352

8/12/2019 ooad sylabus

10/12

Contents xiii

13.4.3 Design 35313.4.5 Test 35413.5 M ak e the Initial Business Case 35413.5.1 Outline Business Bid 35413.5.2 Estimate Return on Investment 35613.6 Assess the Iteration(s) in the Inception Phase 35613.7 Planning the Elaboration Phase 35713.8 The Deliverables for the Inception Phase 358

Chapter 14:The Elaboration Phase Makes theArchitec tural Baseline 35914.1 The Elaboration Phase in Brief 35914.2 Early in the Elaboration Phase 360

14.2.1 Planning the Elaboration Phase 36114.2.2 Building the Team 36114.2.3 Modifying the Developm ent Environment 36114.2.4 S etting Evaluation Criteria 36114.3 The Archetypal Elaboration Iteration Wo rkflow 36214.3.1 Capture and Refine Most of the Requirements 36314.3.2 Develop the Architectural Baseline 36414.3.3 Iterate While the Team Is Sma ll 36414.4 Execute the Core W orkflows Requ irements to Test 36414.4.1 Capture the Requirements 36514.4.2 Analysis 36714.4.3 Design 37214.4.4 Implem entation 37414.4.5 Test 37614.5 M ake the Business Case 37714.5.1 Prepare the Business Bid 37814.5.2 Update Return on Investment 37814.6 Assess the Iterations in the Elaboration Phase 37814.7 Planning the Construction Phase 37914.8 The Key Deliverables 380

Chapter 15: Construction Leads to Initial Operational Capability 38115.1 The Construction Phase in Brief 38215.2 Early in the Construction Phase 38215.2.1 S taffing the Phase 38315.2.2 Setting the Evaluation Criteria 38315.3 The Archetypal Construction Iteration Wo rkflow 384

8/12/2019 ooad sylabus

11/12

xiv Contents

15.4 Execute the Core Wo rkflows Requirements to Testing 38515.4.1 Requ irements 38715.4.2 Analysis 38815.4.3 Design 38915.4.4 Implem entation 39015.4.5 Test 39115.5 Controlling the Business Case 39315.6 Assess the Iterations and the Construction Phase 39315.7 Planning the Transition Phase 39315.8 The Key Deliverables 394Chapter 16: Transition Completes Product Release 395

16.1 The Transition Phase in Brief 39616.2 Early in the Transition Phase 39716.2.1 Planning the Transition Phase 39716.2.2 Staffing the Transition Phase 39916.2.3 Setting the Evaluation Criteria 39916.3 Th e Core Wo rkflows Play a Small Role in this Phase 40016.4 What We Do in the Transition Phase 40116.4.1 Ge tting the Beta Release Out 40116.4.2 Installing the Beta Release 40216.4.3 Respond ing to the Test Results 40216.4.4 Adapting the Product to Varied User Environments 40316.4.5 Com pleting the Artifacts 40416.4.6 When Does the Project End? 40416.5 Com pleting the Business Case 40516.5.1 Con trolling Progress 40516.5.2 Review of the Business Plan 40516.6 Assess the Transition Phase 40616.6.1 Assess the Iterations and the Phase 40616.6.2 Postm ortem of the Project 40716.7 Planning the Next Release or Gen eration 40716.8 The Key Deliverables 407Chapter 17: Making the Un ified Process Work 409

17.1 The Unified Process Helps You Deal with Com plexity 40917.1.1 The Life Cycle Objectives 41017.1.2 The Life Cycle Architecture 41017.1.3 Initial Operationa l Capab ility 41117.1.4 Product Release 411

8/12/2019 ooad sylabus

12/12

Contents xv

17.2 The Major Them es 41117.3 Ma nage me nt Leads Conversion to Unified Process 41217.3.1 The Case for Action 41317.3.2 The Reeng ineering Directive Persuades 41317.3.3 Implemen ting the Transition 41417.4 Specializing the Unified Process 41617.4.1 Tailoring the Process 41617.4.2 Filling in the Process Framework 41717.5 Relate to the Broader Com munity 41817.6 Get the Benefits of the Unified Process 41817.7 References 419Appendix A: Overview of the UML 421

A.1 Introduction 421A.1.1 Vocabulary 422A.1.2 Extensibility Mechanisms 422A.2 Graphical Notation 423A.2.1 Structural Things 423A.2.2 Behavioral Things 424A.2.3 Grouping Things 425A.2.4 Anno tational Things 425A.2.5 Dependency Relationships 425A.2.6 Assoc iation Relationships 425A.2.7 Generalization Relationships 426A.2.8 Extensibility Mech anisms 426A.3 Glossary of Terms 426A.4 References "433

Appendix B: The Unified Process-Specific Extensions of the UML 435B.1 Introduction 435B.2 Stereotypes 435B.3 Tagged Values 438B.4 Graphical Notation 439B.5 References 439

Appendix C: General Glossary 441C.1 Introduction' 441C.2 Terms 441

Index 451