| About the Authors |
|
xv | |
| About the Technical Reviewer |
|
xvii | |
| Acknowledgments |
|
xix | |
| Introduction |
|
xxi | |
|
PART 1 ICONIX and Agility |
|
|
|
What Is Agility? (And Why Does It Matter?) |
|
|
3 | (22) |
|
What Software Agility Isn't |
|
|
5 | (1) |
|
Big Up-front Requirements Gathering and Design |
|
|
5 | (1) |
|
|
|
5 | (1) |
|
|
|
5 | (1) |
|
Low Levels of Communication |
|
|
5 | (1) |
|
``Carrying'' Mediocre Developers |
|
|
5 | (1) |
|
|
|
5 | (1) |
|
|
|
6 | (1) |
|
Why Is Agility Important? |
|
|
7 | (1) |
|
What Makes a Project Agile? |
|
|
8 | (3) |
|
Tuning the Process As You Go Along |
|
|
8 | (1) |
|
|
|
8 | (1) |
|
Enhancing Agility Through Good Design |
|
|
8 | (1) |
|
Improving Communication and Teamwork |
|
|
9 | (1) |
|
Reducing Exposure to the Forces of Change |
|
|
10 | (1) |
|
Measuring Progress with Working Software |
|
|
10 | (1) |
|
|
|
10 | (1) |
|
|
|
10 | (1) |
|
|
|
11 | (1) |
|
Delivering the System That the Customer Wants at the End of the Project, Not What He Thought He Wanted at the Start |
|
|
11 | (1) |
|
Challenges of Being Agile |
|
|
11 | (2) |
|
|
|
11 | (1) |
|
|
|
11 | (1) |
|
|
|
12 | (1) |
|
Doing Less Without Increasing Risk |
|
|
12 | (1) |
|
Discovering Your True Master |
|
|
12 | (1) |
|
Keeping the Customer Involved |
|
|
12 | (1) |
|
|
|
12 | (1) |
|
|
|
12 | (1) |
|
Avoiding the Other Extreme |
|
|
13 | (1) |
|
Facing Resistance to Change |
|
|
13 | (1) |
|
|
|
13 | (9) |
|
|
|
14 | (2) |
|
|
|
16 | (1) |
|
|
|
16 | (2) |
|
Agile Database Techniques |
|
|
18 | (1) |
|
Adaptive Software Development |
|
|
18 | (1) |
|
|
|
18 | (1) |
|
|
|
19 | (1) |
|
|
|
19 | (1) |
|
Feature-Driven Development |
|
|
20 | (1) |
|
|
|
21 | (1) |
|
Agile Fact or Fiction: What Does ``Being Agile'' Mean? |
|
|
22 | (1) |
|
|
|
23 | (1) |
|
Top 10 Practices and Values That Make a Project Agile |
|
|
23 | (2) |
|
Characteristics of a Good Software Process |
|
|
25 | (14) |
|
What's in a Software Development Process? |
|
|
26 | (2) |
|
|
|
26 | (1) |
|
Planning and Phasing Strategy |
|
|
26 | (1) |
|
Human-Centric and Communication Issues |
|
|
27 | (1) |
|
|
|
27 | (1) |
|
|
|
27 | (1) |
|
What Makes a Good Agile Logical Process? |
|
|
28 | (3) |
|
We Need an Obvious Logical Flow |
|
|
28 | (1) |
|
We Don't Want Unnecessary Dependencies Slowing Us Down |
|
|
29 | (1) |
|
We Want Each Step to Clearly Move Us Toward Our True Goal of Working Software |
|
|
29 | (1) |
|
We Want Guidance That Will Reduce Unnecessary Work Later On |
|
|
29 | (1) |
|
We Want Help Prioritizing, Scoping, Planning and Estimating, and Monitoring Work |
|
|
30 | (1) |
|
We Want Broad Steps That Provide General Guidance |
|
|
30 | (1) |
|
We Don't Have to Do Every Step (to the Nth Degree) |
|
|
30 | (1) |
|
We Can Undertake Additional Activities (Coding, in Particular) at Any Point |
|
|
30 | (1) |
|
|
|
31 | (3) |
|
|
|
31 | (1) |
|
|
|
31 | (1) |
|
|
|
31 | (1) |
|
|
|
32 | (1) |
|
|
|
32 | (1) |
|
|
|
32 | (2) |
|
Agile Fact or Fiction: Team Structure and Human Factors |
|
|
34 | (4) |
|
Being Agile Means Placing a Strong Emphasis on Human Factors |
|
|
35 | (1) |
|
Being Agile Means There Are No Role Divisions (Architect, Senior Developer) Within the Development Team---Everyone Is Equal |
|
|
35 | (1) |
|
Being Agile Means the Team Must ``Collectively Own'' the Code Base (with No Room for Specialization) |
|
|
36 | (1) |
|
Being Agile Means Your Entire Team Must Program in Pairs for All Production Code |
|
|
36 | (1) |
|
Being Agile Means There Is No Need for Testers---the Developers Can Test the System Themselves |
|
|
36 | (1) |
|
Being Agile Means You Can Get Top Results with Mediocre Developers |
|
|
37 | (1) |
|
Being Agile Means You Can Work Only with Top Developers |
|
|
37 | (1) |
|
Being Agile Means There Is Never a Role for Analysts |
|
|
37 | (1) |
|
Being Agile Means You Must Work in a Single Office with a Good Seating Arrangement and Lots of Whiteboards |
|
|
38 | (1) |
|
|
|
38 | (1) |
|
ICONIX Process: A Core UML Subset |
|
|
39 | (22) |
|
A Brief History of ICONIX Process |
|
|
40 | (1) |
|
What Can ICONIX Process Do for My Project? |
|
|
41 | (1) |
|
ICONIX Process in Theory (aka Disambiguation and Prefactoring) |
|
|
41 | (3) |
|
|
|
42 | (1) |
|
|
|
43 | (1) |
|
ICONIX Process in a Nutshell |
|
|
44 | (9) |
|
Step 1: Identify Your Real-World Domain Objects |
|
|
45 | (2) |
|
Step 2: Define the Behavioral Requirements |
|
|
47 | (1) |
|
Step 3: Perform Robustness Analysis to Disambiguate the Use Cases and Identify Gaps in the Domain Model |
|
|
48 | (2) |
|
Step 4: Allocate Behavior to Your Objects |
|
|
50 | (1) |
|
Step 5: Finish the Static Model |
|
|
51 | (1) |
|
Step 6: Write/Generate the Code |
|
|
52 | (1) |
|
Step 7: Perform System and User-Acceptance Testing |
|
|
52 | (1) |
|
More About Disambiguation |
|
|
53 | (3) |
|
Do the Domain Model First to Avoid Ambiguity in the Use Cases |
|
|
53 | (1) |
|
Using Robustness Analysis to Disambiguate the Use Cases |
|
|
54 | (2) |
|
More About Prefactoring and Model Refactoring |
|
|
56 | (1) |
|
|
|
56 | (3) |
|
|
|
56 | (1) |
|
Core Analysis Modeling Practices |
|
|
57 | (1) |
|
Core Design Modeling Practices |
|
|
57 | (1) |
|
|
|
57 | (2) |
|
|
|
59 | (2) |
|
A Core Subset of Agile Practices |
|
|
61 | (28) |
|
Why Define a Core Subset of Agile Practices? |
|
|
61 | (1) |
|
Agile ICONIX: The Core Subset of Agile Practices |
|
|
61 | (10) |
|
|
|
63 | (6) |
|
Agile Values That Drive the Agile Practices |
|
|
69 | (2) |
|
Refactoring the Agile Manifesto |
|
|
71 | (4) |
|
|
|
71 | (2) |
|
Boiling Down the Values to Their Essence |
|
|
73 | (1) |
|
Giving the Customers What They Want |
|
|
73 | (1) |
|
Refactored Manifesto Summary |
|
|
74 | (1) |
|
Agile Fact or Fiction (Continued) |
|
|
75 | (10) |
|
Modeling and Documentation |
|
|
75 | (3) |
|
Change and Change Management |
|
|
78 | (1) |
|
Customer- and Contract-Related Issues |
|
|
79 | (1) |
|
|
|
80 | (3) |
|
|
|
83 | (2) |
|
Concluding Fact or Fiction |
|
|
85 | (1) |
|
|
|
85 | (4) |
|
PART 2 Agile ICONIX Process in Practice: The Mapplet Project |
|
|
|
Introducing the Mapplet Project |
|
|
89 | (12) |
|
So, What's a Mapplet, Anyway? |
|
|
89 | (3) |
|
|
|
92 | (1) |
|
|
|
92 | (3) |
|
Project Inception: A JumpStart Workshop in Action |
|
|
95 | (1) |
|
|
|
96 | (1) |
|
Initial Use Case Modeling for the Mapplet |
|
|
97 | (1) |
|
|
|
98 | (1) |
|
More Information on ArcGIS As Used by the Mapplet |
|
|
99 | (1) |
|
ArcGIS Software Developer Kit |
|
|
99 | (1) |
|
ArcGIS Server Terminology |
|
|
100 | (1) |
|
|
|
100 | (1) |
|
Modeling the Mapplet (Release 1) |
|
|
101 | (22) |
|
Beginning with a Prototype (and Just a Little Bit of Modeling) |
|
|
101 | (1) |
|
Visual Acceptance Testing |
|
|
102 | (1) |
|
First Pass Modeling Efforts (and Some Typical Modeling Mistakes) |
|
|
103 | (5) |
|
|
|
108 | (5) |
|
The ``Generate Hotel Map for AOI'' Use Case |
|
|
109 | (4) |
|
Let's Take a Look at Some Code |
|
|
113 | (8) |
|
Source Code for the ``Generate Hotel Map for AOI'' Use Case |
|
|
115 | (5) |
|
|
|
120 | (1) |
|
Et Voila! The First (Working Prototype) Release |
|
|
121 | (1) |
|
|
|
122 | (1) |
|
Synchronizing the Model and Code: One Small Release at a Time |
|
|
123 | (26) |
|
|
|
123 | (1) |
|
Divergence of Code and Design over Time |
|
|
124 | (1) |
|
|
|
125 | (22) |
|
``Display Rollover Information'' Robustness Diagram Revisited |
|
|
125 | (5) |
|
``Display Rollover Information'' Sequence Diagram Revisited |
|
|
130 | (6) |
|
|
|
136 | (1) |
|
Source Code for the Refactored Design |
|
|
137 | (9) |
|
When to Keep the Model and the Code Tightly Interwoven |
|
|
146 | (1) |
|
``And Today's Lesson Is . . .'' |
|
|
147 | (1) |
|
|
|
147 | (2) |
|
|
|
149 | (24) |
|
Customer Feedback on the First Release |
|
|
149 | (1) |
|
How Persona Analysis Was Used to Drive the Requirements |
|
|
150 | (2) |
|
Using Personas to Identify Requirements |
|
|
150 | (1) |
|
Was This the Right Time for Persona Analysis on the Mapplet Project? |
|
|
151 | (1) |
|
Planning the Second Release |
|
|
152 | (5) |
|
High-Level Requirements for Release 2 |
|
|
152 | (1) |
|
|
|
152 | (1) |
|
|
|
153 | (1) |
|
|
|
154 | (2) |
|
|
|
156 | (1) |
|
|
|
157 | (1) |
|
|
|
157 | (1) |
|
|
|
158 | (2) |
|
|
|
158 | (1) |
|
|
|
159 | (1) |
|
Source Code: Refactoring Is Still Useful After Doing Use Case--Driven Modeling |
|
|
160 | (7) |
|
Screenshots of the Finished Product |
|
|
167 | (1) |
|
Agile Scorecard for the Mapplet Project |
|
|
168 | (1) |
|
|
|
169 | (4) |
|
PART 3 Extensions to ICONIX Process |
|
|
|
|
|
173 | (16) |
|
|
|
173 | (2) |
|
Balancing Flexibility and Perception |
|
|
173 | (1) |
|
How Agile ICONIX Differs from Other Agile Methods |
|
|
174 | (1) |
|
Example: Agile Planning in Action |
|
|
174 | (1) |
|
Agile Planning Terminology |
|
|
175 | (1) |
|
Agile Planning Building Blocks |
|
|
176 | (7) |
|
Prioritizing Requirements |
|
|
176 | (1) |
|
|
|
177 | (1) |
|
|
|
178 | (1) |
|
Tracking Project Velocity |
|
|
179 | (1) |
|
|
|
180 | (1) |
|
Tracing Requirements Back to Goals |
|
|
181 | (1) |
|
Minimizing the Use of Gantt Charts |
|
|
181 | (2) |
|
|
|
183 | (1) |
|
Modeling: Analysis and Design |
|
|
183 | (1) |
|
|
|
183 | (1) |
|
|
|
184 | (1) |
|
Agile Planning Principles |
|
|
184 | (4) |
|
|
|
184 | (1) |
|
|
|
185 | (1) |
|
|
|
186 | (1) |
|
|
|
186 | (1) |
|
|
|
187 | (1) |
|
All Changes Are Not Equal |
|
|
187 | (1) |
|
|
|
187 | (1) |
|
|
|
188 | (1) |
|
|
|
189 | (14) |
|
Extending ICONIX Process with Persona Analysis |
|
|
189 | (1) |
|
The Three Pieces of the Jigsaw Puzzle |
|
|
190 | (2) |
|
|
|
190 | (1) |
|
|
|
190 | (1) |
|
|
|
190 | (2) |
|
Building the Ul Around a Target User |
|
|
192 | (3) |
|
Writing Interaction Scenarios to Validate the Existing System |
|
|
192 | (1) |
|
Using Interaction Scenarios to Describe New Features |
|
|
193 | (2) |
|
Using Interaction Design to Identify Alternate Scenarios |
|
|
195 | (1) |
|
Keeping a Tight Rein on Complexity |
|
|
196 | (1) |
|
Using Interaction Design to Identify Actors and Use Cases |
|
|
196 | (1) |
|
|
|
197 | (1) |
|
Visual Acceptance Test for Release 2 |
|
|
198 | (3) |
|
|
|
201 | (2) |
|
A ``Vanilla'' Test-Driven Development Example |
|
|
203 | (24) |
|
|
|
204 | (1) |
|
|
|
205 | (20) |
|
Our First Test: Testing for Nothingness |
|
|
206 | (5) |
|
Making CustomerManager Do Something |
|
|
211 | (1) |
|
Our First BookingManager Test: Testing for Nothingness |
|
|
212 | (2) |
|
Adding a Vector: Testing for Something |
|
|
214 | (1) |
|
A Quick Bout of Refactoring |
|
|
215 | (1) |
|
|
|
216 | (3) |
|
Testing for Bookings by More Than One Customer |
|
|
219 | (2) |
|
One Last User Story and We're Done (So We're 90% Complete, Then!) |
|
|
221 | (3) |
|
Leave It for the Next Release |
|
|
224 | (1) |
|
|
|
225 | (1) |
|
|
|
225 | (2) |
|
Test-Driven Development with ICONIX Process |
|
|
227 | (26) |
|
How Agile ICONIX Modeling and TDD Fit Together |
|
|
227 | (1) |
|
The ``Vanilla'' Example Repeated Using ICONIX Modeling and TDD |
|
|
227 | (21) |
|
Implementing the ``Create a New Customer'' Use Case |
|
|
230 | (18) |
|
|
|
248 | (1) |
|
Stop the Presses: Model-Driven Testing |
|
|
249 | (2) |
|
|
|
251 | (2) |
| Index |
|
253 | |
Other versions by this Author
