Acknowledgments |
|
xv | |
About the Editors |
|
xvii | |
|
|
xix | |
Foreword |
|
xxi | |
|
Foreword |
|
xxix | |
|
Preface |
|
xxxi | |
|
Chapter 1 Making Software Architecture and Agile Approaches Work Together: Foundations and Approaches |
|
|
1 | (24) |
|
|
1 | (2) |
|
1.2 Software Architecture |
|
|
3 | (8) |
|
1.2.1 Software Architecture Process and Architecture Lifecycle |
|
|
4 | (2) |
|
1.2.2 Architecturally Significant Requirements |
|
|
6 | (2) |
|
1.2.3 Software Architecture Design Methods |
|
|
8 | (1) |
|
1.2.4 Documenting Software Architecture |
|
|
9 | (1) |
|
1.2.5 Software Architecture Evaluation |
|
|
10 | (1) |
|
1.3 Agile Software Development and Architecture |
|
|
11 | (3) |
|
|
12 | (1) |
|
1.3.2 Extreme Programming |
|
|
13 | (1) |
|
1.4 Making Architectural and Agile Approaches Work |
|
|
14 | (11) |
|
|
18 | (1) |
|
|
19 | (6) |
|
PART 1 FUNDAMENTALS OF AGILE ARCHITECTING |
|
|
|
Chapter 2 The DCI Paradigm: Taking Object Orientation into the Architecture World |
|
|
25 | (38) |
|
|
26 | (2) |
|
|
27 | (1) |
|
2.1.2 Architecture and DCI |
|
|
28 | (1) |
|
2.2 The Vision: What is Architecture? |
|
|
28 | (4) |
|
2.2.1 Why do we do Architecture? |
|
|
29 | (1) |
|
|
29 | (1) |
|
2.2.3 Why Software Architecture? |
|
|
30 | (1) |
|
2.2.4 Architecture and the Agile Agenda |
|
|
31 | (1) |
|
2.2.5 DCI as an Integrative View of the Architecture Metaphor |
|
|
32 | (1) |
|
2.3 Form and Function in Architectural History |
|
|
32 | (5) |
|
2.3.1 Historic Movements and Ideologies |
|
|
34 | (1) |
|
2.3.2 Enter Postmodernism |
|
|
35 | (1) |
|
2.3.3 Architecture Finds an Object Foothold |
|
|
35 | (1) |
|
2.3.4 Software Engineering and Architecture Today |
|
|
36 | (1) |
|
2.3.5 Measures of the Vision |
|
|
36 | (1) |
|
2.4 What is Object Orientation? Achieving the Vision |
|
|
37 | (5) |
|
|
37 | (1) |
|
2.4.2 Mental System Models |
|
|
38 | (1) |
|
2.4.3 Model-View-Controller |
|
|
38 | (1) |
|
|
39 | (1) |
|
|
39 | (1) |
|
2.4.6 Many Views of Objects and the Boundaries of MVC |
|
|
40 | (2) |
|
2.5 Shortcomings of the Models |
|
|
42 | (7) |
|
2.5.1 The Network Paradigm |
|
|
42 | (1) |
|
2.5.2 Model-View-Controller |
|
|
43 | (1) |
|
|
43 | (1) |
|
|
44 | (1) |
|
|
45 | (4) |
|
2.6 DCI as a New Paradigm |
|
|
49 | (5) |
|
|
49 | (3) |
|
2.6.2 Relating DCI to the Original OO Vision |
|
|
52 | (1) |
|
2.6.3 DCI and the Agile Agenda |
|
|
53 | (1) |
|
|
54 | (5) |
|
2.7.1 DCI and the Postmodem View |
|
|
55 | (1) |
|
|
56 | (2) |
|
2.7.3 DCI and the Network Computation View |
|
|
58 | (1) |
|
2.7.4 Firmitas, Utilitas, and Venustas |
|
|
58 | (1) |
|
|
59 | (4) |
|
|
60 | (1) |
|
|
61 | (2) |
|
Chapter 3 Refactoring Software Architectures |
|
|
63 | (20) |
|
|
63 | (1) |
|
3.2 Dealing with Design Flaws |
|
|
64 | (1) |
|
3.3 Evolution and Styles of Refactoring---Code Refactoring |
|
|
65 | (1) |
|
3.4 Evolution and Styles of Refactoring---Refactoring to Patterns |
|
|
66 | (1) |
|
3.5 The Motivation for Software Architecture Refactoring |
|
|
67 | (1) |
|
|
67 | (3) |
|
|
70 | (2) |
|
|
72 | (1) |
|
3.9 The Process of Continuous Architecture Improvement |
|
|
73 | (2) |
|
3.10 Shallow and Deep Refactoring |
|
|
75 | (1) |
|
3.11 Additional Examples of Architecture Refactoring Patterns |
|
|
75 | (3) |
|
3.11.1 Breaking Dependency Cycles |
|
|
75 | (1) |
|
3.11.2 Splitting Subsystems |
|
|
75 | (3) |
|
3.12 Known Obstacles to Architecture Refactoring |
|
|
78 | (1) |
|
3.13 Comparing Refactoring, Reengineering, and Rewriting |
|
|
79 | (2) |
|
|
81 | (2) |
|
|
82 | (1) |
|
Chapter 4 Driving Architectural Design and Preservation From a Persona Perspective in Agile Projects |
|
|
83 | (30) |
|
|
83 | (3) |
|
4.2 Personas in the Design Space |
|
|
86 | (1) |
|
|
87 | (6) |
|
4.3.1 From Features to Architectural Concerns |
|
|
87 | (3) |
|
4.3.2 Embedding Architectural Concerns Into Personas |
|
|
90 | (3) |
|
4.4 Personas for Driving Architectural Design |
|
|
93 | (8) |
|
|
94 | (1) |
|
4.4.2 Generating and Evaluating Architectural Solutions |
|
|
95 | (1) |
|
|
95 | (6) |
|
4.5 Personas and Architectural Preservation |
|
|
101 | (4) |
|
4.5.1 Trace By Subscription |
|
|
103 | (1) |
|
4.5.2 Generating Persona-centric Perspectives |
|
|
103 | (1) |
|
|
103 | (2) |
|
4.6 ASPs in Other Project Domains |
|
|
105 | (4) |
|
4.6.1 Mechatronics Traceability |
|
|
106 | (2) |
|
|
108 | (1) |
|
|
108 | (1) |
|
|
109 | (4) |
|
|
110 | (1) |
|
|
110 | (3) |
|
Chapter 5 Architecture Decisions: Who, How, and When? |
|
|
113 | (26) |
|
|
114 | (1) |
|
|
115 | (1) |
|
5.3 The Agile Architecture Axes Framework |
|
|
116 | (5) |
|
5.3.1 Who Makes the Architectural Decisions? |
|
|
117 | (1) |
|
5.3.2 What Artifacts Are Used to Document the Decision? |
|
|
118 | (1) |
|
5.3.3 What Is the Feedback Loop of An Architectural Decision? |
|
|
119 | (1) |
|
5.3.4 Summary of the Axes |
|
|
120 | (1) |
|
|
121 | (7) |
|
|
121 | (1) |
|
|
122 | (2) |
|
|
124 | (1) |
|
|
125 | (1) |
|
|
126 | (1) |
|
|
127 | (1) |
|
|
128 | (2) |
|
5.5.1 Mapping the Cases to the Triple-A Framework |
|
|
128 | (1) |
|
5.5.2 Identified Problems |
|
|
129 | (1) |
|
|
130 | (1) |
|
|
130 | (2) |
|
|
131 | (1) |
|
5.6.2 Questions of Validity |
|
|
131 | (1) |
|
5.7 Related and Future Work |
|
|
132 | (1) |
|
|
133 | (6) |
|
|
|
A Visual Representation of the Case Studies Mapped on the Triple-A Framework |
|
|
133 | (2) |
|
|
135 | (4) |
|
PART 2 MANAGING SOFTWARE ARCHITECTURE IN AGILE PROJECTS |
|
|
|
Chapter 6 Supporting Variability Through Agility to Achieve Adaptable Architectures |
|
|
139 | (22) |
|
|
139 | (2) |
|
|
141 | (2) |
|
|
141 | (1) |
|
|
142 | (1) |
|
|
143 | (1) |
|
6.4 Challenges when Combining Variability and Agility |
|
|
144 | (1) |
|
6.5 Arguments for Combining Variability and Agility |
|
|
145 | (1) |
|
6.6 Agile-Inspired Variability Handling |
|
|
146 | (9) |
|
6.6.1 Industrial Context: Dutch e-Government |
|
|
148 | (1) |
|
6.6.2 Step 1: Conduct Initial Variability Analysis |
|
|
149 | (1) |
|
6.6.3 Step 2: Create Initial Architecture Variability Profile |
|
|
149 | (1) |
|
6.6.4 Step 3: Create Architecture |
|
|
150 | (1) |
|
6.6.5 Steps 4a and 4b: Evaluate Architecture |
|
|
151 | (3) |
|
6.6.6 Step 5: Implement Initial Architecture |
|
|
154 | (1) |
|
6.6.7 Step 6: Elicit New Variability Requirements |
|
|
154 | (1) |
|
6.6.8 Step 7: Revise Architecture Variability Profile |
|
|
154 | (1) |
|
6.6.9 Step 8: Refactor Architecture |
|
|
155 | (1) |
|
6.7 Summary and Conclusions |
|
|
155 | (6) |
|
|
157 | (1) |
|
|
157 | (4) |
|
Chapter 7 Continuous Software Architecture Analysis |
|
|
161 | (28) |
|
|
161 | (1) |
|
7.2 Software Architecture Analysis |
|
|
162 | (2) |
|
7.3 Approaches to Software Architecture Analysis |
|
|
164 | (3) |
|
7.3.1 Architecture Reviews |
|
|
164 | (1) |
|
7.3.2 Scenario-Based Evaluation Methods |
|
|
165 | (1) |
|
7.3.3 Architecture Description Languages |
|
|
165 | (1) |
|
7.3.4 Dependency Analysis Approaches and Architecture Metrics |
|
|
166 | (1) |
|
7.3.5 Architecture Prototyping |
|
|
166 | (1) |
|
|
167 | (1) |
|
7.4 Continuous Software Architecture Analysis |
|
|
167 | (4) |
|
7.4.1 CSAA and Different Kinds of Architecture Analysis |
|
|
168 | (1) |
|
7.4.2 Approaches for Continuous Quality Control (CQC) |
|
|
169 | (1) |
|
7.4.3 Characteristics of CQC Approaches |
|
|
169 | (1) |
|
|
170 | (1) |
|
7.5 CSAA in Existing Approaches |
|
|
171 | (2) |
|
7.6 CSAA and Analysis Goals |
|
|
173 | (3) |
|
7.7 Experiences With An Approach to CSAA |
|
|
176 | (6) |
|
|
179 | (3) |
|
7.8 Findings and Research Challenges |
|
|
182 | (1) |
|
|
183 | (6) |
|
|
184 | (5) |
|
Chapter 8 Lightweight Architecture Knowledge Management for Agile Software Development |
|
|
189 | (26) |
|
|
189 | (2) |
|
8.2 Challenges of Agile Architecture Documentation |
|
|
191 | (2) |
|
8.3 Supporting Techniques for AKM in Agile Software Development |
|
|
193 | (5) |
|
8.3.1 Architecture Evaluation Methods, Agility, and AKM |
|
|
194 | (2) |
|
8.3.2 Advanced Techniques for Managing Architectural Repositories |
|
|
196 | (2) |
|
8.4 Architecture Practices in Agile Projects |
|
|
198 | (3) |
|
|
198 | (1) |
|
8.4.2 Architecting While Using Scrum |
|
|
199 | (2) |
|
8.5 Architectural Information Flow in Industry |
|
|
201 | (4) |
|
|
201 | (1) |
|
|
202 | (2) |
|
8.5.3 General Comments From Interviewees |
|
|
204 | (1) |
|
|
205 | (1) |
|
|
205 | (3) |
|
8.6.1 Big-up-front-Architecture and Sprint-Zero Architecting Approaches |
|
|
205 | (2) |
|
8.6.2 In-sprints Architecting Approach |
|
|
207 | (1) |
|
8.6.3 Separated-architecture-team Architecting Approach |
|
|
207 | (1) |
|
|
208 | (1) |
|
|
209 | (6) |
|
|
210 | (1) |
|
|
211 | (4) |
|
Chapter 9 Bridging User Stories and Software Architecture: a Tailored Scrum for Agile Architecting |
|
|
215 | (30) |
|
|
215 | (2) |
|
|
217 | (1) |
|
9.3 Case Study: Metering Management System in Electrical Power Networks |
|
|
218 | (3) |
|
9.4 Agile Architecting Mechanisms |
|
|
221 | (11) |
|
9.4.1 Feature Pool and Feature Tree of User Stories |
|
|
221 | (4) |
|
9.4.2 Flexibility in Software Architecture Design |
|
|
225 | (5) |
|
9.4.3 Agile Design Decisions: CIA Support |
|
|
230 | (2) |
|
9.5 A Tailored Scrum for Agile Architecting |
|
|
232 | (2) |
|
9.6 Agile Architecting in Practice |
|
|
234 | (3) |
|
9.7 Findings About Agile Architecting |
|
|
237 | (8) |
|
|
238 | (1) |
|
|
239 | (6) |
|
PART 3 AGILE ARCHITECTING IN SPECIFIC DOMAINS |
|
|
|
Chapter 10 Architecture-Centric Testing for Security: An Agile Perspective |
|
|
245 | (24) |
|
|
245 | (1) |
|
|
246 | (2) |
|
10.3 Overview of Limitations in Current Post-implementation Methods |
|
|
248 | (3) |
|
10.3.1 Functional Testing of Security Apparatuses |
|
|
248 | (1) |
|
10.3.2 Penetration Testing |
|
|
248 | (1) |
|
|
249 | (1) |
|
|
250 | (1) |
|
10.4 Introducing Implied Scenarios |
|
|
251 | (2) |
|
10.4.1 Detecting Implied Scenarios |
|
|
251 | (2) |
|
|
253 | (1) |
|
10.5.1 Stage 1: Implied Scenario Detection |
|
|
253 | (1) |
|
10.5.2 Stage 2: Review of Detected Implied Scenarios |
|
|
253 | (1) |
|
10.5.3 Stage 3: Performing Live Security Testing |
|
|
254 | (1) |
|
10.6 The Agility of the Approach |
|
|
254 | (1) |
|
10.7 Identity Management Case Study |
|
|
255 | (5) |
|
10.7.1 Case Study Background |
|
|
256 | (1) |
|
10.7.2 Approach and Results |
|
|
256 | (4) |
|
|
260 | (3) |
|
10.9 Agile Development, Architecture, and Security Testing |
|
|
263 | (1) |
|
|
264 | (1) |
|
|
265 | (4) |
|
|
265 | (4) |
|
Chapter 11 Supporting Agile Software Development and Deployment in the Cloud: a Multitenant, Multitarget Architecture |
|
|
269 | (22) |
|
|
269 | (2) |
|
|
271 | (1) |
|
11.3 Multitenancy Architectures |
|
|
272 | (2) |
|
11.4 Agility and Multitenant Architectures |
|
|
274 | (1) |
|
11.5 Multitenancy Monotarget: Agility Challenges |
|
|
275 | (1) |
|
11.6 Supporting Agility: Multitenancy Multitarget |
|
|
276 | (5) |
|
11.6.1 Functional Portfolio Management |
|
|
278 | (1) |
|
11.6.2 Multitarget Metadata (MT2 Metadata) |
|
|
278 | (1) |
|
11.6.3 Business Process Reutilization |
|
|
279 | (2) |
|
11.6.4 Multitarget Security |
|
|
281 | (1) |
|
11.7 Globalgest: a Real MT2 System |
|
|
281 | (3) |
|
|
284 | (1) |
|
11.9 Conclusions and Future Work |
|
|
285 | (6) |
|
|
286 | (5) |
|
PART 4 INDUSTRIAL VIEWPOINTS ON AGILE ARCHITECTING |
|
|
|
Chapter 12 Agile Architecting: Enabling the Delivery of Complex Agile Systems Development Projects |
|
|
291 | (24) |
|
12.1 Agile and Complex Systems Development Approaches Need to Merge and Adapt |
|
|
292 | (3) |
|
12.1.1 Why do Complex System Development Best Practices Need to Incorporate Agile Best Practices? |
|
|
293 | (1) |
|
12.1.2 Why do Complex System Development Projects Need Architecture? |
|
|
294 | (1) |
|
12.2 Identifying the Right Amount of Architecture |
|
|
295 | (2) |
|
12.3 Cost Reduction Through Architecture |
|
|
297 | (2) |
|
12.3.1 Reduce Costs By Enabling the Use of Off-shore Development |
|
|
297 | (1) |
|
12.3.2 Reduce Costs By Considering Total Cost of Ownership (TCO) |
|
|
298 | (1) |
|
12.4 Minimize Rework Through Architecture |
|
|
299 | (3) |
|
12.4.1 Minimize Rework Through Reasonable Foresight |
|
|
299 | (1) |
|
12.4.2 Minimize Rework Via Prototypes |
|
|
300 | (2) |
|
12.5 Accelerate Delivery Through Architecture |
|
|
302 | (11) |
|
12.5.1 Accelerate the Delivery Pipeline By Incorporating Multiple Perspectives |
|
|
302 | (1) |
|
12.5.2 Accelerate Delivery By Maximizing Capacity |
|
|
303 | (3) |
|
12.5.3 Accelerate Delivery Through Early Integration |
|
|
306 | (2) |
|
12.5.4 Accelerate Delivery Via Early and Continuous Testing |
|
|
308 | (3) |
|
12.5.5 Accelerate Delivery Via An Automated Deployment Pipeline |
|
|
311 | (2) |
|
|
313 | (2) |
|
|
314 | (1) |
|
Chapter 13 Building a Platform for Innovation: Architecture and Agile as Key Enablers |
|
|
315 | (20) |
|
|
315 | (1) |
|
|
316 | (1) |
|
13.3 An Architecture Heritage |
|
|
317 | (2) |
|
13.4 Iterative Development |
|
|
319 | (2) |
|
|
321 | (2) |
|
13.6 Agile With Discipline |
|
|
323 | (3) |
|
13.7 Beyond Architecture and Agile |
|
|
326 | (6) |
|
13.7.1 Define a Project Lifecycle Selection Framework |
|
|
326 | (2) |
|
|
328 | (1) |
|
13.7.3 Consider All Elements of a Development Environment |
|
|
329 | (1) |
|
13.7.4 Adopt Change Incrementally |
|
|
330 | (1) |
|
13.7.5 Implement a Center of Excellence |
|
|
331 | (1) |
|
|
332 | (3) |
|
|
333 | (2) |
|
Chapter 14 Opportunities, Threats, and Limitations of Emergent Architecture |
|
|
335 | (22) |
|
|
335 | (3) |
|
14.1.1 A Brief Definition of Emergence |
|
|
336 | (1) |
|
14.1.2 The Idea of Emergent Architecture |
|
|
336 | (2) |
|
14.2 Purpose, Activities, and Objectives of Architecture |
|
|
338 | (4) |
|
14.2.1 Purpose---the Why of Architecture |
|
|
339 | (1) |
|
14.2.2 Activities---the How of Architecture |
|
|
340 | (1) |
|
14.2.3 Objectives---the What of Architecture |
|
|
341 | (1) |
|
14.3 Analysis of Emergent Architecture |
|
|
342 | (7) |
|
|
343 | (2) |
|
|
345 | (1) |
|
14.3.3 Implementation of Nonfunctional Requirements |
|
|
346 | (1) |
|
14.3.4 Design for Understandability |
|
|
346 | (1) |
|
|
347 | (2) |
|
|
349 | (5) |
|
14.4.1 Comparison of Explicit and Emergent Architecture |
|
|
349 | (3) |
|
|
352 | (2) |
|
|
354 | (3) |
|
|
355 | (2) |
|
Chapter 15 Architecture as a Key Driver for Agile Success: Experiences At Aviva UK |
|
|
357 | (18) |
|
|
357 | (2) |
|
15.2 Challenges to Agile Adoption At Aviva UK |
|
|
359 | (1) |
|
15.3 The Key Role of Architecture in Driving Agile Success |
|
|
360 | (12) |
|
15.3.1 Sufficient Up-front Architecture and Design |
|
|
361 | (6) |
|
15.3.2 Layered Architecture Enabling Independent Change Agility |
|
|
367 | (4) |
|
15.3.3 "Change-time" Architecture and "run-time" Architecture |
|
|
371 | (1) |
|
15.4 Incremental Agile and Architecture Transformation |
|
|
372 | (1) |
|
|
373 | (2) |
|
|
374 | (1) |
Author Index |
|
375 | (8) |
Subject Index |
|
383 | |