Agile Systems Engineering (eBook)
452 Seiten
Elsevier Science (Verlag)
978-0-12-802349-5 (ISBN)
Embedded Software Methodologist. Triathlete. Systems engineer. Contributor to UML and SysML specifications. Writer. Black Belt. Neuroscientist. Classical guitarist. High school dropout. Bruce Powel Douglass, who has a doctorate in neurocybernetics from the USD Medical School, has over 35 years of experience developing safety-critical real-time applications in a variety of hard real-time environments. He is the author of over 5700 book pages from a number of technical books including Real-Time UML, Real-Time UML Workshop for Embedded Systems, Real-Time Design Patterns, Doing Hard Time, Real-Time Agility, and Design Patterns for Embedded Systems in C. He is the Chief Evangelist at IBM Rational, where he is a thought leader in the systems space and consulting with and mentors IBM customers all over the world. He can be followed on Twitter @BruceDouglass. Papers and presentations are available at his Real-Time UML Yahoo technical group (http://tech.groups.yahoo.com/group/RT-UML) and from his IBM thought leader page (www-01.ibm.com/software/rational/leadership/thought/brucedouglass.html).
Agile Systems Engineering presents a vision of systems engineering where precise specification of requirements, structure, and behavior meet larger concerns as such as safety, security, reliability, and performance in an agile engineering context. World-renown author and speaker Dr. Bruce Powel Douglass incorporates agile methods and model-based systems engineering (MBSE) to define the properties of entire systems while avoiding errors that can occur when using traditional textual specifications. Dr. Douglass covers the lifecycle of systems development, including requirements, analysis, design, and the handoff to specific engineering disciplines. Throughout, Dr. Douglass couples agile methods with SysML and MBSE to arm system engineers with the conceptual and methodological tools they need to avoid specification defects and improve system quality while simultaneously reducing the effort and cost of systems engineering. - Identifies how the concepts and techniques of agile methods can be effectively applied in systems engineering context- Shows how to perform model-based functional analysis and tie these analyses back to system requirements and stakeholder needs, and forward to system architecture and interface definition- Provides a means by which the quality and correctness of systems engineering data can be assured (before the entire system is built!)- Explains agile system architectural specification and allocation of functionality to system components- Details how to transition engineering specification data to downstream engineers with no loss of fidelity- Includes detailed examples from across industries taken through their stages, including the "e;Waldo"e; industrial exoskeleton as a complex system
Front Cover 1
Agile Systems Engineering 4
Copyright Page 5
Dedication 6
Contents 8
About the Author 16
Preface 18
Audience 19
Goals 19
Tooling 20
Where to Go After the Book 20
Acknowledgments 22
1 What Is Model-Based Systems Engineering? 24
1.1 Key Systems Engineering Activities 26
1.1.1 Identifying Customer Needs 27
1.1.2 Specifying System Requirements 28
1.1.3 Assess Dependability 28
1.1.4 Evaluating Alternative Architectures and Technologies 29
1.1.5 Selecting Specific Architectures and Technologies 30
1.1.6 Allocating Requirements and Interfaces to Architectures 30
1.1.7 Hand Off to Downstream Engineering 30
1.1.8 Integrate Discipline-Specific Designs into System Composite 31
1.1.9 Verify System as a Whole 31
1.1.9.1 Syntactic verification 32
Audits 32
Syntactic reviews 32
1.1.9.2 Semantic verification 33
Semantic review 33
Testing 34
Formal methods 34
1.1.9.3 System verification 35
1.1.10 System Validation 35
1.2 Systems Engineering Data 36
1.2.1 System Development Plan 36
1.2.2 Stakeholder Requirements 36
1.2.3 System Requirements 37
1.2.4 Certification Plan 37
1.2.5 Subsystem Requirements 37
1.2.6 Discipline-Specific Requirements 37
1.2.7 Safety Analysis 37
1.2.8 Reliability Analysis 38
1.2.9 Security Analysis 38
1.2.10 System Architecture 38
1.2.10.1 Subsystems 38
1.2.10.2 Deployment architecture 39
1.2.10.3 Dependability architecture 39
1.2.10.4 Distribution architecture 39
1.2.11 Integration Test Plan 40
1.2.12 Integration Tests 40
1.2.13 Verification Plan 40
1.2.14 Verification Tests 40
1.2.15 Validation Plan 41
1.2.16 Trace Matrix 41
1.2.17 Integration Test Results 42
1.2.18 Verification Results 42
1.2.19 Validation Results 42
1.3 Lifecycles of the Systems Engineer 42
1.3.1 V-Model Lifecycle 43
1.3.2 Incremental 44
1.3.3 Hybrid 46
1.4 Model-Based Systems Engineering (MBSE) 46
1.4.1 The Modeling Advantage 48
1.4.1.1 Precision of engineering data 48
1.4.1.2 Data consistency across work products and engineering activities 48
1.4.1.3 A common source of engineering truth 49
1.4.1.4 Improved visualization and comprehension of engineering data 50
1.4.1.5 Ease of integration of disparate engineering data 50
1.4.1.6 Improved management and maintenance of engineering data 50
1.4.1.7 Early verification of the correctness of engineering data 51
1.4.2 High-Precision Modeling with UML and SysML 51
1.4.2.1 The fundamental truth of modeling: drawing?modeling 51
1.4.3 Modeling Is Essential for Agile Systems Engineering 52
1.4.3.1 The fundamental truth of agile systems engineering: verifiable models are required for agile systems engineering 52
1.4.4 Adopting Modeling in Your Organization or Project 54
1.4.4.1 Antipatterns of adopting MBSE 54
1.4.4.2 Recommend approaches for adopting MBSE 54
Assessment 55
Planning for adoption 57
Pilot 58
Deployment 58
1.4.5 The Rules (of Modeling) 59
1.5 Summary 62
References 62
2 What Are Agile Methods and Why Should I Care? 64
2.1 The Agile Manifesto 66
2.2 Benefits of Agile Methods 69
Improved Quality of Engineering Data 69
Improved Engineering Efficiency 70
Early Return on Investment (ROI) 70
Satisfied Stakeholders 70
Increased Project Control 70
Responsiveness to Change 71
Earlier and Greater Reduction in Project Risk 71
2.3 Applying the Agile Manifesto to Systems Engineering 71
2.3.1 Work Incrementally 71
2.3.2 Plan Dynamically 72
2.3.3 Actively Reduce Project Risk 73
2.3.4 Verify Constantly 74
2.3.5 Integrate Continuously 74
2.3.6 Use Case 1: Find Tracks in Airspace 75
2.3.7 Use Case 2: Perform Periodic Built in Test (PBIT) 75
2.3.8 Validate Frequently 76
2.3.9 Modeling Is Essential for aMBSE 76
2.4 Agile Best Practices for Systems Engineering 76
2.4.1 Incremental Development of Work Products 76
2.4.2 Continual Verification of Work Products 77
2.4.3 Executable Requirements Models 78
2.4.4 Model-Based Specification Linked to Textual Specification 79
2.4.5 Continuous Dependability Assessment 81
2.4.6 Active Project Risk Management 82
2.4.7 Model-Based Hand Off to Downstream Engineering 84
2.4.8 Dynamic Planning 84
2.5 Putting It All Together: The Harmony Agile MBSE (aMBSE) Process 86
2.5.1 Initiate Project 89
2.5.2 Define Stakeholder Requirements 91
2.5.3 System Requirements Definition and Analysis 93
2.5.4 Approach 1: Flow-based Use Case Analysis 94
2.5.5 Approach 2: Scenario-based Use Case Analysis 95
2.5.6 Approach 3: State-based Use Case Analysis 95
2.5.7 Architectural Analysis 97
2.5.8 Architectural Design 97
2.5.9 Perform Iteration Retrospective 102
2.5.10 Handoff to Downstream Engineering 102
2.5.11 Control Project 104
2.5.12 Perform Quality Assurance Audits 105
2.5.13 Manage Change 105
2.6 Summary 106
References 107
3 SysML Introduction 108
3.1 SysML at 30,000 Feet 109
3.2 UML Extension Mechanisms 113
3.2.1 SysML Model Elements 115
3.2.2 SysML Diagrams 116
3.2.3 Behavior Diagrams 117
3.2.3.1 Activity diagram 117
3.2.3.2 Sequence diagram 118
3.2.3.3 State machine diagram 118
3.2.3.4 Use case diagram 118
3.2.4 Requirement Diagram 119
3.2.5 Structure Diagrams 120
3.2.5.1 Package diagram 120
3.2.5.2 Block definition diagram 121
3.2.5.3 Internal block diagram 121
3.2.5.4 Parametric diagram 123
3.3 Organize Your Models Like It Matters 124
3.4 Key SysML Views and Core Semantics 130
3.4.1 Blocks, Relations, Interfaces, and Ports 130
3.4.1.1 Blocks 130
3.4.1.2 Block instances 131
3.4.1.3 Association 132
3.4.1.4 Flows 133
3.4.1.5 Aggregation 133
3.4.1.6 Composition 134
3.4.1.7 Connector 135
3.4.1.8 Generalization 135
3.4.1.9 Dependencies 137
3.4.1.10 Ports 137
Standard ports 137
Interfaces 138
Proxy ports 139
Interface blocks 139
Flow properties and flow items 140
Full ports 140
3.4.1.11 Parts 141
3.4.2 Sequence Diagrams 142
3.4.3 Activities, Actions, and Activity Diagrams 146
3.4.3.1 Some subtle semantics 151
3.4.4 State Machine Diagrams 153
3.4.4.1 Definitions 154
3.4.4.2 Basic state machines 154
3.4.4.3 Nested states 159
3.4.4.4 Submachines 160
3.4.4.5 AND-states 162
3.4.4.6 Pseudostates 163
3.4.4.7 Activity diagrams or state machines? 165
3.5 Minimal SysML Profile 165
3.5.1 Diagrams 165
3.6 Summary 167
3.6.1 Copied from the UML 168
3.6.2 Modifications 168
3.6.3 New Elements 168
References 168
4 Agile Stakeholder Requirements Engineering 170
4.1 Objectives 171
4.2 The Stakeholder Requirements Workflow 172
4.2.1 Remember—This Is Agile MBSE 173
4.2.2 So, What Is a Use Case? 174
4.2.2.1 General properties of good use cases 174
Coherence 175
Independence 175
Coverage 175
Size (10–100 requirements, 3–50 scenarios) 175
Exception for large systems 176
Return a result visible to an actor 176
4.2.2.2 Some things to avoid with use cases 176
Implying or revealing internal system structure 177
Using use cases to decompose system internals 177
Use cases that are too small 178
Dependent use cases 178
Too many relations among use case 178
Associations between use cases 178
4.2.3 Use Case Diagrams 179
4.2.3.1 An example: the Speed Demon Treadmill 179
4.2.3.2 Use cases 179
4.2.3.3 Actors 180
4.2.3.4 Relations 182
4.2.3.5 Association 182
4.2.3.6 Generalization 182
4.2.3.7 «Include» 182
4.2.3.8 «Extend» 183
4.2.3.9 «Allocate» 183
4.3 The Example Model: T-Wrecks, the Industrial Exoskeleton 184
4.4 Identifying Stakeholders 185
4.4.1 Pilot 186
4.4.2 Fleet Manager 186
4.4.3 Maintainer 187
4.4.4 Purchaser 187
4.4.5 Installer 187
4.4.6 The T-Wreckers Testing Team 187
4.4.7 Manufacturing Engineer 187
4.5 Generating Stakeholder Requirements 187
4.5.1 What’s a Requirement? 188
4.5.2 Performance and Other QoS Requirements 190
4.5.3 Visualizing Requirements 191
4.5.4 Requirements Management Tools 191
4.5.5 Organizing the Stakeholder Requirements Specification 194
4.6 Modeling Stakeholder Use Cases Scenarios 194
4.6.1 What Is a Use Case Scenario, Exactly? 195
4.6.2 Scenario Analysis Workflow 197
4.6.2.1 How do you know when you’re done? 199
4.6.3 T-Wrecks Stakeholder Use Case Scenarios 201
4.6.3.1 Proximity detection use case 201
4.6.3.2 Move joint use case 202
4.7 Create/Update Validation Plan 209
4.8 Summary 209
4.8.1 Identify Stakeholders 210
4.8.2 Generate Stakeholder Requirements 210
4.8.3 Model Stakeholder Use Case Scenarios 210
4.8.4 Create/Update Validation Plan 211
4.9 Moving On 211
Reference 211
5 Agile Systems Requirements Definition and Analysis 212
5.1 Objectives 213
5.1.1 Let’s Get Technical 213
5.2 The Systems Requirements Workflow 214
5.2.1 Identify System Use Cases 215
5.2.2 Generating/Updating System Requirements 216
5.2.3 Perform Use Case Analysis 216
5.2.3.1 Flow-based approach for use case analysis 216
5.2.3.2 Scenario-based approach for use case analysis 217
5.2.3.3 State-based approach for use case analysis 217
5.2.4 Create Logical Data Schema 217
5.2.5 Analyze Dependability 217
5.2.6 Create/Update System Verification Plan 218
5.3 Identify System Use Cases 218
5.4 Generating System Requirements 218
5.4.1 Allocating Requirements to System Use Cases 219
5.5 Analyzing Use Cases 220
5.5.1 Flow-Based Use Case Analysis 220
5.5.1.1 Define the use case context 221
Packages 222
Actor blocks 222
Activity and state 222
5.5.1.2 Derive use case functional flow 223
5.5.1.3 Define use case scenarios 224
5.5.1.4 Define ports and interfaces 225
5.5.1.5 Derive use case state machine 226
5.5.1.6 Verify and validate functional requirements 229
5.5.1.7 Add traceability links 229
5.5.1.8 Perform review 230
5.5.1.9 T-Wrecks flow-based use case analysis 230
Step 1: Use case execution context 231
Step 2: Derive use case functional flow 233
Step 3: Define use case scenarios 235
Step 4: Define ports and interfaces 236
Step 5: Derive use case state behavior 238
Step 6: Verify and validate functional requirements 239
Step 7: Add traceability links 239
Step 8: Perform review 240
5.5.2 Scenarios-Based Use Case Analysis 240
5.5.2.1 Define the use case context 243
5.5.2.2 Define use case scenarios 243
5.5.2.3 Derive use case functional flow 244
5.5.2.4 Define ports and interfaces 246
5.5.2.5 Derive use case state machine 246
How much simulation fidelity do you need? 251
5.5.2.6 T-Wrecks scenario-based use case analysis 253
Step 1: Use case execution context 253
Step 2: Define use case scenarios 254
Step 3: Derive use case functional flow 256
Step 4: Define ports and interfaces 257
Step 5: Derive use case state behavior 259
Step 6: Verify and validate functional requirements 261
5.5.3 State-Based Use Case Analysis 262
5.5.3.1 Define the use case context 263
5.5.3.2 Derive use case state machine 264
5.5.3.3 Define use case scenarios 268
5.5.3.4 Define ports and interfaces 270
5.5.3.5 T-Wrecks state-based use case analysis 271
Step 1: Use case execution context 272
Step 2: Derive use case state behavior 272
Step 3: Create scenarios 274
Step 4: Define ports and interfaces 276
Step 5: Verify and validate functional requirements 277
5.6 Create/Update Logical Data Schema 278
5.7 Dependability Analysis 283
5.7.1 Safety Analysis 284
5.7.1.1 Reliability analysis 290
Steps to creating a FMEA 290
5.7.1.2 Security analysis 291
5.7.2 T-Wrecks Initial Dependability Analysis 297
5.7.2.1 T-Wrecks safety 297
5.7.2.2 T-Wrecks reliability 297
5.7.2.3 T-Wrecks security 299
5.8 Create/Update Verification Plan 300
5.9 Summary 301
5.10 Moving On 301
References 302
6 Agile Systems Architectural Analysis and Trade Studies 304
6.1 Objectives 305
6.2 Architecture Analysis Workflow 306
6.2.1 Identify Key System Functions 307
6.2.2 Define Candidate Solutions 307
6.2.3 Perform Architectural Trade Study 307
6.2.4 Merge Solutions into Systems Architecture 308
6.2.5 Define Assessment Criteria 309
6.2.6 Assign Weights to Criteria 309
6.2.7 Define Utility Curve for Each Criterion 309
6.2.8 Assign MOEs to Candidate Solutions 309
6.2.9 Determine the Solution 310
6.3 Assessment Methodology 310
6.3.1 The Easy Way 310
6.3.2 The High-Fidelity Way 312
6.4 Identify Key System Functions (and Properties) 316
6.5 Define the Candidate Solutions 319
6.5.1 Speed Demon Candidate Solutions 319
6.5.2 T-Wrecks Candidate Solutions 320
6.5.2.1 Ultrasonic 321
6.5.2.2 Lidar scanning unit 321
6.5.2.3 Lidar rangefinder 321
6.6 Perform the Architectural Trade Study 324
6.6.1 Define the Assessment Criteria 324
6.6.1.1 Speed Demon 324
6.6.1.2 T-Wrecks 325
6.6.2 Assign Weights to the Criteria 325
6.6.3 Define the Utility Curve for Each Criterion 325
6.6.4 Assign MOEs to Candidate Solutions 328
6.6.5 Determine the Solution 330
6.7 Merge the Solutions into the Systems Architecture 331
6.8 Summary 333
6.9 Moving On 334
References 334
7 Agile Systems Architectural Design 336
7.1 Objectives 337
7.1.1 So … What’s a Subsystem? 337
7.1.2 Key Architectural Views 339
7.2 Architectural Design Workflow 341
7.2.1 Identify Subsystems 341
7.2.2 Allocate System Requirements to Subsystems 342
7.2.3 Allocate Use Cases to Subsystems 342
7.2.4 Create/Update Logical Data Schema 343
7.2.5 Create/Update Subsystem Requirements 343
7.2.6 Develop Control Laws 343
7.2.7 Analyze Dependability 343
7.2.8 Perform Review 344
7.3 Identify Subsystems 344
7.3.1 Speed Demon Subsystems 346
7.3.2 T-Wrecks Subsystems 354
7.4 Allocate System Requirements to Subsystems 358
7.5 Allocate Use Cases to Subsystems 359
7.5.1 Bottom-Up Allocation 360
7.5.1.1 Derive white box scenarios 360
7.5.1.2 Define subsystem ports and interfaces 361
7.5.1.3 Group services into use cases 361
7.5.2 Top-Down Allocation 361
7.5.2.1 Decompose use cases to subsystem level 361
7.5.2.2 Define subsystem-level scenarios 363
7.5.2.3 Define subsystem ports and interfaces 364
7.5.3 Common Tasks 364
7.5.3.1 Derive use case state behavior 364
7.5.3.2 Verify and validate functional requirements 364
7.5.3.3 Add traceability links 364
7.5.3.4 Perform review 365
7.5.4 Speed Demon Subsystem Use Case Allocation Example 365
7.5.5 T-Wrecks Subsystem Use Case Allocation Example 371
7.6 Create/Update Logical Data Schema 376
7.6.1 Speed Demon Treadmill Example 377
7.6.2 T-Wrecks Example 381
7.7 Create/Update Subsystem Requirements 382
7.8 Develop Control Laws 383
7.9 Analyze Dependability 385
7.9.1 Safety Analysis 386
7.9.2 Reliability Analysis 386
7.9.3 Security Analysis 386
7.10 Summary 386
7.11 Moving On 388
References 388
8 The Handoff to Downstream Engineering 390
8.1 Objectives 391
8.2 The Handoff to Downstream Engineering Workflow 391
8.2.1 Gather Subsystem Specification Data 391
8.2.2 Create the Shared Model 392
8.2.3 Define Subsystem Physical Interfaces 392
8.2.4 Create Subsystem Model 393
8.2.5 Define Interdisciplinary Interfaces 393
8.2.6 Allocation Requirements to Engineering Disciplines 393
8.3 Gather Subsystem Specification Data 394
8.3.1 Gathering SysML Model Data 394
8.3.2 Gathering Other Engineering Data 395
8.4 Create the Shared Model 396
8.4.1 Organizing the Shared Model 396
8.5 Define Subsystem Physical Interfaces 398
8.5.1 Creating Physical Specifications from Logical Specifications 398
8.5.1.1 Refine the logical service into a physical service 402
8.5.1.2 Refine the data schema 402
8.5.1.3 Refine the constraints 402
8.5.1.4 Put the physical interface and data into the shared model 402
8.5.2 Speed Demon Interface Example 402
8.5.3 T-Wrecks Interface Example 405
8.6 Create Subsystem Model 409
8.7 Define Interdisciplinary Interfaces 411
8.7.1 Speed Demon Example: Control Unit Subsystem Interface Specification 412
8.7.2 T-Wrecks Example 414
8.7.2.1 The Coordination subsystem 414
8.7.2.2 The Limb Assembly subsystem 416
8.8 Allocation Requirements to Engineering Disciplines 420
8.8.1 Speed Demon Example 420
8.8.2 T-Wrecks Example 420
8.9 And Downstream Engineering Begins 425
8.10 And System Engineering Continues … 428
References 429
Appendix A: T-Wrecks Stakeholder Requirements 430
Project Overview 430
T-Wrecks High Level Use Cases 430
General Requirements 431
Encase Use Case 431
Balance Use Case 431
Walk Use Case 431
Monitor System Use Case 431
Move Limbs Use Case 432
Manage Power Use Case 432
Startup Use Case 432
Self Test Use Case 433
Provide Visibility Use Case 433
Monitor System Use Case 433
Shutdown Use Case 433
Proximity Detection Use Case 433
Configure Use Case 433
Communicate Use Case 434
Appendix B: T-Wrecks System Requirements 436
T-Wrecks High Level Use Cases 436
Requirements Table (Initial Set) 437
Index 442
Back Cover 453
What Are Agile Methods and Why Should I Care?
Chapter 2 introduces agile methods and their application to systems engineering. Although agile methods arose in IT software development, they have begun to be applied——with good success—in other engineering disciplines as well. In order to understand how best to apply them to systems engineering, a good understanding of the basic agile concepts, methods, and approaches is necessary. This chapter outlines the Agile Manifesto and restates it to be more relevant to systems engineering, including identifying the important measure of success—verified engineering data. The benefits of agile approaches are explained with an emphasis on the difference it can make to systems engineers. Key methodological approaches—incremental engineering, dynamic planning, continuous verification (of engineering data), continuous integration, and so on—are all explained in the context of systems engineering.
The chapter highlights the key agile best practices for improving quality and efficiency in systems engineering and then outlines the Harmony Agile Model-Based Systems Engineering (Harmony aMBSE) process that integrates those best practices into a coherent approach.
Keywords
Agile; harmony agile MBSE process; agile best practices; agile systems engineering
Chapter Outline
2.2 Benefits of Agile Methods 46
2.3 Applying the Agile Manifesto to Systems Engineering 48
2.3.3 Actively Reduce Project Risk 50
2.3.5 Integrate Continuously 51
2.3.6 Use Case 1: Find Tracks in Airspace 52
2.3.7 Use Case 2: Perform Periodic Built in Test (PBIT) 52
2.3.9 Modeling Is Essential for aMBSE 53
2.4 Agile Best Practices for Systems Engineering 53
2.4.1 Incremental Development of Work Products 53
2.4.2 Continual Verification of Work Products 54
2.4.3 Executable Requirements Models 55
2.4.4 Model-Based Specification Linked to Textual Specification 56
2.4.5 Continuous Dependability Assessment 58
2.4.6 Active Project Risk Management 59
2.4.7 Model-Based Hand Off to Downstream Engineering 61
2.5 Putting It All Together: The Harmony Agile MBSE (aMBSE) Process 63
2.5.2 Define Stakeholder Requirements 68
2.5.3 System Requirements Definition and Analysis 70
2.5.4 Approach 1: Flow-based Use Case Analysis 71
2.5.5 Approach 2: Scenario-based Use Case Analysis 72
2.5.6 Approach 3: State-based Use Case Analysis 72
2.5.7 Architectural Analysis 74
2.5.9 Perform Iteration Retrospective 79
2.5.10 Handoff to Downstream Engineering 79
2.5.12 Perform Quality Assurance Audits 82
2.6 Summary 83
References 84
Agile methods are largely a response to increasing regimentation of software development and work that was only tangentially related to the development of the software itself. It is also a reaction to the fact that despite the burden of this additional work, the quality of the software is low and the software far too often doesn’t meet the needs of its intended users. Although agile was originally conceived for small software projects, we will see that there is much to recommend it for other endeavors, including (and of great interest here) systems engineering.
From an overview perspective, agile methods are really about optimizing development along two dimensions—product quality and engineering efficiency. Many people think it’s about what you DON’T do—you DON’T plan, document, fill out paper work, design, analyze, or create requirements. In actuality, agile is more about what you DO and the order in which you do them. Agile methods are meant to be adaptive and responsive to different situations and changing needs using objective evidence to guide how work it done.
Put another way, it isn’t so much that you do different things when you do agile methods as much as the order and sequence of those things is changed. This facilitates early feedback as to the correctness and adequacy of the work and work products you create. For example, traditional methods1 do a “breadth-first” approach to creating work products and defer the verification of those work products at least until they are complete, and often much later. Agile, on the other hand, incrementally verifies the work products as they are being created. That provides more immediate feedback as to the correctness of the work product and how well your process is helping you achieve your engineering goals.
I liken the agile approach to dental hygiene. Imagine that you want to ensure your “tooth quality” by applying the “tooth brushing quality step.” Because you view this as important, at the end of every year, on December 31, you do a good and thorough job of brushing your teeth and verifying their quality, and then going to a dentist for tooth quality problem remediation. Much to your dismay, your tooth quality is pretty low and requires extraordinary measures (and no small amount of discomfort) to bring the quality up. That is how the traditional approach works with deferred verification.
Imagine instead performing this quality improvement and assessment step immediately after using your teeth (i.e., after meals). Through constant application of quality methods, the quality of your teeth remains high throughout the year. This is a more hygienic approach and avoids big quality problems more than identifying them late for defect removal. In either case, you’re performing quality assurance activities to both improve and verify quality but what is different is when those activities are performed. Agile methods perform quality assurance activities throughout the development of important work products rather than after they are completed. That is, when these activities are performed, we optimize defect avoidance rather than defect identification.
Oh, and Agilistas DO plan, document, fill out paper work, design, analyze, and create requirements. We’ll talk about how those activities can be done in an agile systems engineering environment in some detail in this book.
2.1 The Agile Manifesto
A good place to start to understand agile methods is with the agile manifesto.2 The manifesto is a public declaration of intent by the Agile Alliance, consisting of 17 signatories including Kent Beck, Martin Fowler, Ron Jeffries, Robert Martin, and others. Originally drafted in 2001, this manifesto is summed up in four key statements:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan.
A thing to note about the manifesto is that it states an emphasis, not an exclusion. We emphasize working software over documentation, but that doesn’t mean that we don’t write documentation. We emphasize responsiveness to change over dogmatically following a plan, but that doesn’t mean that we don’t plan. The point is to pay more attention to the things that really matter. Paying attention to meeting the customer’s needs and creating correct software is more important than following the plan and writing the documentation, but it doesn’t mean that these other aspects don’t get any attention at all.
To support the statements of the manifesto, the Agile Alliance give a set of 12 principles. I’ll state them here to set the context of the following discussion:
• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying...
| Erscheint lt. Verlag | 24.9.2015 |
|---|---|
| Sprache | englisch |
| Themenwelt | Mathematik / Informatik ► Informatik ► Programmiersprachen / -werkzeuge |
| Informatik ► Software Entwicklung ► Agile Software Entwicklung | |
| ISBN-10 | 0-12-802349-X / 012802349X |
| ISBN-13 | 978-0-12-802349-5 / 9780128023495 |
| Informationen gemäß Produktsicherheitsverordnung (GPSR) | |
| Haben Sie eine Frage zum Produkt? |
EPUB (Adobe DRM)Kopierschutz: Adobe-DRM
Adobe-DRM ist ein Kopierschutz, der das eBook vor Mißbrauch schützen soll. Dabei wird das eBook bereits beim Download auf Ihre persönliche Adobe-ID autorisiert. Lesen können Sie das eBook dann nur auf den Geräten, welche ebenfalls auf Ihre Adobe-ID registriert sind.
Details zum Adobe-DRM
Dateiformat: EPUB (Electronic Publication)
EPUB ist ein offener Standard für eBooks und eignet sich besonders zur Darstellung von Belletristik und Sachbüchern. Der Fließtext wird dynamisch an die Display- und Schriftgröße angepasst. Auch für mobile Lesegeräte ist EPUB daher gut geeignet.
Systemvoraussetzungen:
PC/Mac: Mit einem PC oder Mac können Sie dieses eBook lesen. Sie benötigen eine
eReader: Dieses eBook kann mit (fast) allen eBook-Readern gelesen werden. Mit dem amazon-Kindle ist es aber nicht kompatibel.
Smartphone/Tablet: Egal ob Apple oder Android, dieses eBook können Sie lesen. Sie benötigen eine
Geräteliste und zusätzliche Hinweise
Buying eBooks from abroad
For tax law reasons we can sell eBooks just within Germany and Switzerland. Regrettably we cannot fulfill eBook-orders from other countries.
aus dem Bereich
