;Advance Praise for Head First Software Development;Praise for Head First Object-Oriented Analysis and Design;Praise for Head First Design Patterns; ; Author(s) of Head First Software Development;How to use this Book: Intro; Who is this book for?; We know what you''re thinking; We know what your brain is thinking; Metacognition: thinking about thinking; Here''s what WE did; Read Me; The technical review team; Acknowledgments; Safari® Books Onli≠Chapter 1: Great Software Development: Pleasing your customer; 1.1 Tom''s Trails is going onli≠ 1.2 Most projects have two major concerns; 1.3 The Big Bang approach to development; 1.4 Flash forward: two weeks later; 1.5 Big bang development usually ends up in a BIG MESS; 1.6 Great software development is.; 1.

7 Getting to the goal with ITERATION; 1.8 Each iteration is a mini-project; 1.9 Each iteration is QUALITY software; 1.10 The customer WILL change things up; 1.11 It''s up to you to make adjustments; 1.12 Iteration handles change automatically (well, sort of); 1.13 Your software isn''t complete until it''s been RELEASED; 1.14 Tools for your Software Development Toolbox;Chapter 2: Gathering Requirements: Knowing what the customer wants; 2.

1 Orion''s Orbits is modernizing; 2.2 Talk to your customer to get MORE information; 2.3 Bluesky with your customer; 2.4 Sometimes your bluesky session looks like this.; 2.5 Find out what people REALLY do; 2.6 Your requirements must be CUSTOMER-oriented; 2.7 Develop your requirements with customer feedback; 2.

8 User stories define the WHAT of your project. estimates define the WHEN; 2.9 Cubicle conversation; 2.10 Playing planning poker; 2.11 Put assumptions on trial for their lives; 2.12 A BIG user story estimate is a BAD user story estimate; 2.13 The goal is convergence; 2.14 The requirement to estimate iteration cyc≤ 2.

15 Finally, you''re ready to estimate the whole project.; 2.16 Tools for your Software Development Toolbox;Chapter 3: Project Planning: Planning for success; 3.1 Customers want their software NOW!; 3.2 Prioritize with the customer; 3.3 We know what''s in Milestone 1.0 (well, maybe); 3.4 If the features don''t fit, reprioritize; 3.

5 More people sometimes means diminishing returns; 3.6 Work your way to a reasonable Milestone 1.0; 3.7 Iterations should be short and sweet; 3.8 Comparing your plan to reality; 3.9 Velocity accounts for overhead in your estimates; 3.10 Programmers think in UTOPIAN days.; 3.

11 Developers think in REAL-WORLD days.; 3.12 When is your iteration too long?; 3.13 Deal with velocity BEFORE you break into iterations; 3.14 Time to make an evaluation; 3.15 Managing pissed off customers; 3.16 The Big Board on your wall; 3.17 How to ruin your team''s lives; 3.

18 Tools for your Software Development Toolbox;Chapter 4: User Stories and Tasks: Getting to the real work; 4.1 Introducing iSwoon; 4.2 Do your tasks add up?; 4.3 Plot just the work you have left; 4.4 Add your tasks to your board; 4.5 Start working on your tasks; 4.6 A task is only in progress when it''s IN PROGRESS; 4.7 What if I''m working on two things at once?; 4.

8 Your first standup meeting.; 4.9 Task 1: Create the Date class; 4.10 Standup meeting: Day 5, end of Week 1.; 4.11 Standup meeting: Day 2, Week 2.; 4.12 You have to track unplanned tasks; 4.

13 Unexpected tasks raise your burn-down rate; 4.14 Velocity helps, but.; 4.15 We originally calculated velocity as.; 4.16 So we have this much "float".; 4.17 .

but it may not be enough!; 4.18 We have a lot to do.; 4.19 .but we know EXACTLY where we st∧Chapter 5: Good-Enough Design: Getting it done with great design; 5.1 iSwoon is in serious trouble.; 5.2 This design breaks the single responsibility princip≤ 5.

3 Spotting multiple responsibilies in your design; 5.4 Going from multiple responsibilies to a single responsibility; 5.5 Your design should obey the SRP, but also be DRY.; 5.6 The post-refactoring standup meeting.; 5.7 Unplanned tasks are still just tasks; 5.8 Part of your task is the demo itself; 5.

9 When everything''s complete, the iteration''s do≠Chapter 6: Version Control: Defensive development; 6.1 You''ve got a new contract--BeatBox Pro; 6.2 And now the GUI work.; 6.3 And a quick test.; 6.4 And Bob does the same.; 6.

5 Demo the new BeatBox for the customer; 6.6 Standup meeting; 6.7 Let''s start with VERSION CONTROL; 6.8 First set up your project.; 6.9 .then you can check code in and out.; 6.

10 Most version control tools will try and solve problems for you; 6.11 The server tries to MERGE your changes; 6.12 If your software can''t merge the changes, it issues a conflict; 6.13 Now show the customer.; 6.14 More iterations, more stories.; 6.15 Standup meeting; 6.

16 We have more than one version of our software.; 6.17 Good commit messages make finding older software easier; 6.18 Now you can check out Version 1.0; 6.19 (Emergency) standup meeting; 6.20 Tag your versions; 6.21 Tags, branches, and trunks, oh my!; 6.

22 Fixing Version 1.0.for real this time.; 6.23 We have TWO code bases now; 6.24 When NOT to branch.; 6.25 We fixed ersion 1.

; 6.26 . and Bob finished ersion 2.0 (so he says); 6.27 Version control can''t make sure your code actually works.; 6.28 Tools for your Software Development Toolbox;Chapter 6 ½: Building your Code: Insert tab a into slot b.; 7.

1 Developers aren''t mind readers; 7.2 Building your project in one step; 7.3 Ant: a build tool for Java projects; 7.4 Projects, properties, targets, tasks; 7.5 Good build scripts.; 7.6 Good build scripts go BEYOND the basics; 7.7 Your build script is code, too; 7.

8 New developer, take two; 7.9 Tools for your Software Development Toolbox;Chapter 7: Testing and Continuous Integration: Things fall a∂ 8.1 Things will ALWAYS go wrong.; 8.2 Standup meeting; 8.3 There are three ways to look at your system.; 8.4 Black-box testing focuses on INPUT and OUTPUT; 8.

5 Grey-box testing gets you CLOSER to the code; 8.6 White-box testing uses inside knowled≥ 8.7 Testing EVERYTHING with one step; 8.8 Automate your tests with a testing framework; 8.9 Use your framework to run your tests; 8.10 At the wheel of CI with CruiseControl; 8.11 Testing guarantees things will work. right?; 8.

12 Standup meeting; 8.13 Testing all your code means testing EVERY BRANCH; 8.14 Use a coverage report to see what''s covered; 8.15 Getting good coverage isn''t always easy.; 8.16 Standup meeting; 8.17 Tools for your Software Development Toolbox;Chapter 8: Test-Driven Development: Holding your code accountab≤ 9.1 Test FIRST, not last; 9.

2 So we''re going to test FIRST.; 9.3 Welcome to test-driven development; 9.4 Your first test.; 9.5 . fails miserably.; 9.

6 Get your tests to GREEN; 9.7 Red, green, refactor.; 9.8 In TDD, tests DRIVE your implementation; 9.9 Completing a task means you''ve got all the tests you need, and they all pass; 9.10 When your tests pass, move on!; 9.11 Different task, same process; 9.12 Red: write (failing) tests; 9.

13 Green: write code to pass tests; 9.14 Simplicity means avoiding dependencies; 9.15 Always write testable code; 9.16 When things get hard to test, examine your design; 9.17 The strategy pattern provides for multiple implementations of a single interface; 9.18 Keep your test code with your tests; 9.19 Testing produces better code; 9.20 More tests always means lots more code; 9.

21 Strategy patterns, loose couplings, object stand ins.; 9.22 We need lots of different, but similar, objects; 9.23 What if we generated objects?; 9.24 A mock object stands in for real objects; 9.25 Mock objects are working object stand-ins; 9.26 Good software is testable.; 9.

27 It''s not easy bein'' green.; 9.28 A day in the life of a test-driven developer.; 9.29 Tools for your Software Development Toolbox;Chapter 9: Ending an Iteration: It''s all coming together.; 10.1 Your iteration is just about complete.; 10.

2 . but there''s lots left you could do; 10.3 Standup Meeting; 10.4 System testing MUST be done.; 10.5 . but WHO does system testing?; 10.6 System testing depends on a complete system to test; 10.

7 Good system testing requires TWO iteration cycles; 10.8 More iterations means more problems; 10.9 The life (and death) of a bug; 10.10 So you found a bug.; 10.11 Anatomy of a bug report; 10.12 But there''s still plenty left you COULD do.; 10.

13 Time for the iteration review; 10.14 Some iteration review questions; 10.15 A GENERAL priority list for getting EXTRA things done.; 10.16 Tools for your Software Development Toolbox;Chapter 10: The Next Iteration: If it ain''t broke. you still better fix it; 11.1 What is working software?; 11.2 You need to plan for the next iteration; 11.

3 Velocity accounts for. the REAL WORLD; 11.4 And it''s STILL about the customer; 11.5 Someone else''s software is STILL just software; 11.6 Customer approval? Check!; 11.7 Testing your code; 11.8 Houston, we really do have a problem.; 11.

9 Standup meeting; 11.10 Trust NO O≠ 11.11 You without your process; 11.12 You with your process;Chapter 11: Bugs: Squashing bugs like a pro; 12.1 First, you''ve got to talk to the customer; 12.2 Standup meeting; 12.3 Priority one: get things buildab≤ 12.4 We could fix code.

; 12.5 . but we need to fix functionality; 12.6 Figure out what functionality works; 12.7 NOW you know what''s not working; 12.8 Spike test to estimate; 12.9 What do the spike test results tell you?; 12.10 Your team''s gut feeling matters; 12.

11 Give your customer the bug fix estimate; 12.12 Things are looking good.; 12.13 . and you finish the iteration successfully!; 12.14 AND most importantly the customer is happy; 12.15 Tools for your Software Development Toolbox;Chapter 12: The Real World: Having a process in life; 13.1 Pinning down a software development process; 13.

2 A good process delivers good software; 13.3 Formal attire required.; 13.4 Some additional resources.; 13.5 More knowledge == better process; 13.6 Tools for your Soft.