Software Development Cross Solution - Index of - Free

More documents

Recommendations

Info

user stories and use cases #3. User stories and use cases You used user stories throughout this book to capture your requirements. User stories are really great at getting a neat description of exactly what the customer needs your software to do. But a lot of more formal processes recommend something called a use case. Luckily, there’s easily enough overlap between user stories and use cases for you to use either technique to capture your customer’s requirements: A user story and a use case describe ONE THING that your software needs to do. 438 Appendix i A user story that describes sending a picture using the Beatbox software from chapter 6. Title: Send a picture to other users Click on the “Send a Picture” button to send a picture (only JPEG needs to be supported) to the other users. The other user should have the option to not accept the file. There are no size limits on the file being sent. Description: 20 4 Priority: Estimate: ...and only one thing. Download at WoweBook.Com A user story that has been prepared for your project board contains a priority and an estimate
An equivalent Use Case that describes the same “Send a picture to other users” requirement Observation is a key component in getting good use cases written. A use case’s sequence normally contains more steps and detail than a user story. This makes it easier to work to for developers, but means extra work with the customer to nail these details down. 1. Click on the “Send a Picture button” 2. Display users the picture can be sent to in the address book list box. 2a. Enter the destination user’s name in the search box 2b. Click on search to find the user 3. Select the user to send the picture to 4. Click on send Send a picture to other users 5. The receiver is asked if they want to accept the photo 5a.1. The receiver accepts the photo 5a.2. The receiver views the photo 5b.1. The recevier rejects the photo 5b.2. The photo is trashed. So what’s the big difference? Well, actually not a lot, really. User stories are usually around three lines long, and are accompanied by an estimate and a priority, so the information is all in one bite-sized place. Use cases are usually reasonably more detailed descriptions of a user’s interaction with the software. Use cases also aren’t usually written along with a priority or an estimate—those details are often captured elsewhere, in more detailed design documentation. User stories are ideally written by the customer, whereas traditionally use cases are not. Ultimately either approach does the same job, capturing what your customer needs your software to do. And one use case, with alternate paths (different ways to use the software in a specific situation) may capture more than one user story. Download at WoweBook.Com leftovers You can add more detail to your user story, or modify your use case to have a little less detail... it’s really up to you and your customer. There are a number of different ways that you can write down a use case. This one describes the interactions that a user has with the software, step by step. you are here 4 439
Page 2 and 3:
Download at WoweBook.Com
Page 4 and 5:
Praise for Head First Object-Orient
Page 6 and 7:
Other related books from O’Reilly
Page 8 and 9:
Head First Software Development by
Page 10 and 11:
the authors Author(s) of Head First
Page 12 and 13:
table of contents x 1 If The Goal g
Page 14 and 15:
table of contents xii 3 project pla
Page 16 and 17:
table of contents xiv 5 good-enough
Page 18 and 19:
table of contents xvi 6 / It buildi
Page 20 and 21:
table of contents xviii 8 Sometimes
Page 22 and 23:
table of contents xx 10 Think the n
Page 24 and 25:
table of contents xxii 12 You’ve
Page 26 and 27:
table of contents xxiv ii appendix
Page 28 and 29:
how to use this book Who is this bo
Page 30 and 31:
how to use this book xxviii intro W
Page 32 and 33:
how to use this book Here’s what
Page 34 and 35:
how to use this book Read Me This i
Page 36 and 37:
the review team The technical revie
Page 38 and 39:
safari books online Safari® Books
Page 40 and 41:
Tom’s Trails Tom’s Trails is go
Page 42 and 43:
the Big Bang approach The Big Bang
Page 44 and 45:
the Big Bang ends with a big mess B
Page 46 and 47:
great software development is... 8
Page 48 and 49:
delivering with iteration Getting t
Page 50 and 51:
an iteration delivers working softw
Page 52 and 53:
an iteration is a complete developm
Page 54 and 55:
uild a plan out of iterations and f
Page 56 and 57:
deciding on a iteration tempo for y
Page 58 and 59:
change happens The customer WILL ch
Page 60 and 61:
handle change with iteration Iterat
Page 62 and 63:
use the right process for you The r
Page 64 and 65:
CHAPTER 1 your software development
Page 66 and 67:
exercise solutions 28 Chapter 1 1 P
Page 68 and 69:
orion’s orbits Orion’s Orbits i
Page 70 and 71:
equirements start with customer ide
Page 72 and 73:
capturing what’s in your customer
Page 74 and 75:
getting more with role playing and
Page 76 and 77:
customer-oriented requirements Our
Page 78 and 79:
keep your customer in the loop Q: W
Page 80 and 81:
user stories capture what your soft
Page 82 and 83:
estimates come with assumptions 44
Page 84 and 85:
assumptions kill confidence in your
Page 86 and 87:
highlighting assumptions and obtain
Page 88 and 89:
assumptions are killed or become ri
Page 90 and 91:
use your customer effectively 52 Ch
Page 92 and 93:
keep estimates small A BIG user sto
Page 94 and 95:
aim for estimates you and your team
Page 96 and 97:
your estimates are your promise Q:
Page 98 and 99:
develop your estimates cyclically T
Page 100 and 101:
sum your estimates to find out your
Page 102 and 103:
when your project is too long 64 Ch
Page 104 and 105:
Page 106 and 107:
Page 108 and 109:
deliver what you can, when it’s n
Page 110 and 111:
priorities come from your customer
Page 112 and 113:
Title: Description: Est: Title: 15
Page 114 and 115:
factoring in team performance 76 Ch
Page 116 and 117:
uilding achievable milestones Work
Page 118 and 119:
your customer decides priority Titl
Page 120 and 121:
milestone = paid, iteration = on tr
Page 122 and 123:
continuously buildable and runnable
Page 124 and 125:
inging reality to your plan 86 Chap
Page 126 and 127:
velocity applies your real performa
Page 128 and 129:
from ideal to real estimates Progra
Page 130 and 131:
confidence comes at a price When is
Page 132 and 133:
iterations with velocity The maximu
Page 134 and 135:
eality means being honest Title: Es
Page 136 and 137:
eaking realistic but bad news Manag
Page 138 and 139:
introducing the big board The Big B
Page 140 and 141:
happiness is a project that can be
Page 142 and 143:
performance and burn down Work left
Page 144 and 145:
Page 146 and 147:
Page 148 and 149:
introducing iSwoon Introducing iSwo
Page 150 and 151:
eak up user stories into tasks Task
Page 152 and 153:
tasks have estimates Your task desc
Page 154 and 155:
tasks on your board Add your tasks
Page 156 and 157:
moving tasks to in progress Start w
Page 158 and 159:
multiple tasks at the same time Wha
Page 160 and 161:
keep communication flowing with dai
Page 162 and 163:
doing your first task Task 1: Creat
Page 164 and 165:
inging your design to life with a s
Page 166 and 167:
exercise solution The date is asked
Page 168 and 169:
monitoring your progress Standup me
Page 170 and 171:
updating your project board 132 Cha
Page 172 and 173:
updating your project board 134 Cha
Page 174 and 175:
into the second week Standup meetin
Page 176 and 177:
detecting problems with the design
Page 178 and 179:
surprises... 140 Chapter 4 We inter
Page 180 and 181:
dealing with unplanned tasks If the
Page 182 and 183:
velocity doesn’t account for surp
Page 184 and 185:
you know where you are We have a lo
Page 186 and 187:
meet velocity Head First: Welcome,
Page 188 and 189:
inging iSwoon under control iSwoon
Page 190 and 191:
detecting bad design ...you needed
Page 192 and 193:
design refactoring The Date class c
Page 194 and 195:
srp analysis Spotting multiple resp
Page 196 and 197:
single responsibility It makes sens
Page 198 and 199:
don’t repeat yourself Your design
Page 200 and 201:
efactoring iSwoon’s design A date
Page 202 and 203:
standup meeting The post-refactorin
Page 204 and 205:
unplanned work Unplanned tasks are
Page 206 and 207:
good-enough delivers “Good Enough
Page 208 and 209:
end of iteration board When everyth
Page 210 and 211:
exercises 172 Chapter 5 Take each o
Page 212 and 213:
exercise solutions Unplanned tasks
Page 214 and 215:
Page 216 and 217:
introducing beatbox pro You’ve go
Page 218 and 219:
digging into code Here’s the code
Page 220 and 221:
finish the story And now the GUI wo
Page 222 and 223:
merging changes And Bob does the sa
Page 224 and 225:
disaster recovery What went wrong?
Page 226 and 227:
version control in action Let’s s
Page 228 and 229:
1 2 creating a repository First set
Page 230 and 231:
merging changes Most version contro
Page 232 and 233:
identifying conflicts If your softw
Page 234 and 235:
esolving conflicts Make these chang
Page 236 and 237:
dealing with older code More iterat
Page 238 and 239:
dealing with multiple releases We h
Page 240 and 241:
viewing logs Good commit messages m
Page 242 and 243:
tagging revisions (Emergency) stand
Page 244 and 245:
anches and tags 1 Use the mkdir com
Page 246 and 247:
working with branches Fixing Versio
Page 248 and 249:
anches, tags, and subversion Q: I
Page 250 and 251:
avoiding unnecessary branches When
Page 252 and 253:
214 Chapter 6 What version control
Page 254 and 255:
CHAPTER 6 Development Techniques Us
Page 256 and 257:
Page 258 and 259:
uilding buildable software Develope
Page 260 and 261:
introducing ant Ant: a build tool f
Page 262 and 263:
more exercises 224 Chapter 6 ½ Are
Page 264 and 265:
a full build script The javac task
Page 266 and 267:
habits of good build scripts Good b
Page 268 and 269:
even more build script tricks Good
Page 270 and 271:
version control your build script Y
Page 272 and 273:
CHAPTER 6 1/2 Development Technique
Page 274 and 275:
it never rains but it pours Things
Page 276 and 277:
lack box testing There are three wa
Page 278 and 279:
grey box testing Grey-box testing g
Page 280 and 281:
white box testing was Below is a us
Page 282 and 283:
testing functionality BeatB These s
Page 284 and 285:
you create tests test for establish
Page 286 and 287:
one-click testing Testing EVERYTHIN
Page 288 and 289:
making the most of a framework Auto
Page 290 and 291:
continuous integration For you and
Page 292 and 293:
setting up continuous integration A
Page 294 and 295:
tests only cover what you tell them
Page 296 and 297:
tested code is completed code } 258
Page 298 and 299:
putting code to the test 260 Chapte
Page 300 and 301:
100% coverage All three of these te
Page 302 and 303:
using a coverage report Testing all
Page 304 and 305:
the cost of testing Q: How do cover
Page 306 and 307:
is 100% coverage efficient? 268 Cha
Page 308 and 309:
an environment for testing 270 Chap
Page 310 and 311:
exercise solutions 272 Chapter 7 Te
Page 312 and 313:
Page 314 and 315:
test before code Test FIRST, not la
Page 316 and 317:
unit testing Your first test... The
Page 318 and 319:
green means pass Get your tests to
Page 320 and 321:
testing a user story’s functional
Page 322 and 323:
implement a test in code import org
Page 324 and 325:
drive your code with TDD In TDD, te
Page 326 and 327:
task done when tests pass Completin
Page 328 and 329:
first fail Red: write (failing) tes
Page 330 and 331:
keep it simple You can just make up
Page 332 and 333:
simple code is testable code Always
Page 334 and 335:
switching to test code with the str
Page 336 and 337:
where to place your test code Remem
Page 338 and 339:
etter code through testing Testing
Page 340 and 341:
tests = code and lots of it More te
Page 342 and 343:
mock objects We need lots of differ
Page 344 and 345:
using a mock object framework Mock
Page 346 and 347:
why mock objects? Q: These mock obj
Page 348 and 349:
all green, you’re done It’s not
Page 350 and 351:
test, red, code, green A day in the
Page 352 and 353:
Page 354 and 355:
Page 356 and 357:
esults from an iteration Your itera
Page 358 and 359:
daily standup meetings Standup Meet
Page 360 and 361:
urn-down analysis 322 Chapter 9 Bef
Page 362 and 363:
system testing System testing MUST
Page 364 and 365:
incorporating system testing System
Page 366 and 367:
issues with test iterations More it
Page 368 and 369:
enabling communication 330 Chapter
Page 370 and 371:
This is usually called acceptance t
Page 372 and 373:
filing and fixing a bug The life (a
Page 374 and 375:
ug trackers So you found a bug....
Page 376 and 377:
learn from your iteration But there
Page 378 and 379:
different project hurdles 340 Chapt
Page 380 and 381:
iteration reviews Time for the iter
Page 382 and 383:
other things to do A GENERAL priori
Page 384 and 385:
CHAPTER 9 346 Chapter 9 Tools for y
Page 386 and 387:
crossword solution 13 B 1 S Iterati
Page 388 and 389:
an iteration finishes with more tha
Page 390 and 391:
planning the next iteration You nee
Page 392 and 393:
uilding your board for the next ite
Page 394 and 395:
uilding your board for the next ite
Page 396 and 397:
factoring in real velocity Q: A tea
Page 398 and 399:
the customer still rules And it’s
Page 400 and 401:
it’s still software Someone else
Page 402 and 403:
integration tasks on your board Tit
Page 404 and 405:
integrating third-party code How yo
Page 406 and 407:
euse means trust too //... 368 Chap
Page 408 and 409:
when reuse lets you down Testing yo
Page 410 and 411:
trust no one Standup meeting 372 Ch
Page 412 and 413:
looking for problems in reused sour
Page 414 and 415:
finding problems in reused source c
Page 416 and 417:
your process deals with it You with
Page 418 and 419:
oken code happens � � � � Q
Page 420 and 421:
exercise solutions 2 R 1 R 3 E S P
Page 422 and 423:
At the end of the last chapter, thi
Page 424 and 425:
always communicate First, you’ve
Page 426 and 427: prioritize what you do 388 Chapter
Page 428 and 429: ump some things for later 390 Chapt
Page 430 and 431: apply your process Priority one: ge
Page 432 and 433: focus on functionality We could fix
Page 434 and 435: test for bugs Figure out what funct
Page 436 and 437: think about estimating Even though
Page 438 and 439: spike tests Spike test to estimate
Page 440 and 441: estimate what’s left What do the
Page 442 and 443: factor in confidence Your team’s
Page 444 and 445: always communicate Give your custom
Page 446 and 447: apply other techniques Figure out w
Page 448 and 449: successful deliveries matter Things
Page 450 and 451: functionality wins most importantly
Page 452 and 453: CHAPTER 11 414 Chapter 11 Tools for
Page 454 and 455: crossword solution 10 F 15 H 5 P Bu
Page 456 and 457: software process defined Pinning do
Page 458 and 459: evaluate everything The big board 4
Page 460 and 461: ensure changes improve things The b
Page 462 and 463: formalize if necessary Formal attir
Page 464 and 465: other resources Some additional res
Page 466 and 467: CHAPTER 12 428 Chapter 12 Tools for
Page 468 and 469: exercise solutions 4 S 11 P 14 A So
Page 470 and 471: Download at WoweBook.Com
Page 472 and 473: uml and class diagrams #1. UML clas
Page 474 and 475: sequence diagrams #2. Sequence diag
Page 478 and 479: system testing vs. unit testing #4.
Page 482 and 483: CHAPTER 1 development techniques CH
Page 484 and 485: development principles Deliver soft
Page 488 and 489: the index building projects (contin
Page 490 and 491: the index H Head First Java BeatBox
Page 492 and 493: the index No Dumb Questions (contin
Page 494 and 495: the index singularly focused 152 so
Page 496 and 497: the index third-party code bugs in
show all

Software Development Cross Solution - Index of - Free

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?