CS304 Software Engineering Week4 Note

Week4_note

XP is an Iterative Process

• Iteration = two week cycle (1 - 3 weeks)
• Plan each iteration in an iteration meeting that is held at the start of the iteration
• Iteration is going to implement set of user stories
• Divide work into tasks small enough to finish in a day
• Each day, programmers work in pairs to finish task

What are user stories

• A user story represents
  • A feature customers want in the software
• A user story is the smallest amount of information (a step) necessary to allow the customer to define (and steer) a path through the system
• Written by customers(through communication with developers), and not by developers
• Typically written on index cards

Writing user stories

• Material
  • A stack of blank index cards
  • Pens or pencils
  • Rubber bands
• Start with a goal of the system
  • e.g. "Applicant submits a loan application"
  • Think about the step that the user takes as he/she does the activity
  • Write no more than one step on each card

Format of a user story

• Title: 2-3 words
• Acceptance test(unique identifier)
• Priority 1-2-3(1 most important)
• Story points(can mean #days of ideal development, i.e., no distractions or working on other things)

Concepts

• Story point: unit of measure for expressing the overall size of a user story, feature, or other piece of work. The raw value of a story point is unimportant. What matters are the relative values.
  • Related to how hard it is and how much of it there is
  • Not related to amount of time or the number of people
  • Unitless, but numerically-meaningful
• Ideal time: the amount of time "something" takes when stripped of all peripheral activities
• Elapsed time: the amount of time that passes on the clock to do "something"
• Velocity: measure of a team's rate of progress

Priority

• High
• Medium
• Low

Estimating story points

• Choose a medium-size story and assign it a "5"
• Estimate other stories relative to that
  • Twice as big
  • Half as big
  • Almost but not quite as big
  • A little bit bigger
• Only values:
  • 0,1,2,3,5,8,13,20,40,100

Estimating ideal days

• Ideal days vs. elapsed time in software development
  • Supporting current release
  • sick time
  • meetings
  • demonstrations
  • personal issue
  • Phone call
• When estimating ideal days, assume:
  • The story being estimated is the only thing you'll work on
  • Everything you need will be on hand when you start
  • There will be no interruptions

Ideal Days vs. Story Points

• Favoring story points:
  • Help drive cross-functional behavior
  • Do not decay(change based on experience)
  • Are a pure measure of size(focus on feature, not person)
  • Estimation is typically faster in the long run
  • My ideal days are not your ideal days(focus on person and their speed)
• Favoring ideal days;
  • Easier to explain outside of team
  • Estimation is typically faster at first

Deriving an estimate for a user story

• Expert opinion
  • Rely on gut feel based on (extensive) experience
  • disadvantage for agile: need to consider all aspects of developing the user story, so one expert will likely not be enough
• Analogy
  • Relative to (several) other user stories
  • Triangulation: little bigger than that "3" and a little smaller than that"8"
• Disaggregation
  • Break up into smaller, easier-to-estimate pieces/tasks.
  • Need to make sure you don't miss any tasks
  • Sanity check: does the sum of all the parts make sense?
  • Planning poker
    • Combines expert opinion, analogy, disaggregation

Velocity

• Velocity is a measure of a team's rate of progress
• Velocity is calculated by summing the number of story points assigned to each user story that the tea completed during the operation
• We assume that the team will produce in future iterations at the rate of their past average velocity
  • "Yesterdays weather"

Prioritization

• Driven by customer, in conjunction with developer
• Choose features to fill up velocity of iteration, based on:
  • Desirability of feature to a broad base of customers/users
  • Desirability f feature to a small number of important customers/users
  • The cohesiveness of the story in relation to other stories
    • Example:
      • "Zoom in" a high priority feature
      • "Zoom out" not a high priority feature
        • But it becomes one relative to "Zoom in"

Planning game

• Customer writes user stories
• Programmers estimate time to do each story
• If story is too big, customer splits it
• Customer chooses stories to match project velocity
• Project velocity is amount of work done in the previous iteration(s)

Planning

• Programmers only worry about one iteration at a time
• Customer can plan as many iterations as desired, but can change future iterations

Simplicity

• Add one feature(user story) at a time
• Don't worry about future stories
• Make program as simple as possible
• The simplest thing that could possibly work

Need Educated customer

XP works best when

• Educated customer on site
• Small team
• People who like to talk
• All in one room(including customer)
  • These days the room can also be virtual
• Changing requirements

Unit tests and refactoring

• Because code is as simple as it can be, adding a enw feature tends to make it less simple
• To recover simplicity, you must refactor the code
• To refactor safely, yous should have a rigorous set of unit test

Working software

• All software has automated(unit) test
• All test pass, all the time
  • Never check in broken code
• How to work on a task
  • Get latest version of the code. All tests pass
  • Write test first. If fails
  • Write code to make test pass. Now all tests pass
  • Refactor(clean up)
  • Check in your code

One key practice

• Write tests first, then write code
• various name
  • Test-first programming
  • Test-driven development
• Is it testing or designing?
• Degree to which yous tick to if for MP?

Why test?

• Improve quality - find bugs
• Measure quality
  • Prove there are no bugs?
  • Determine if software is ready to be released
  • Determine what to work on
  • See if you made a mistake
• Learn the software
• Grade MPs

What is a Test?

• Run program with known input(test inputs/data), check results (with test oracles)
  • Test pass (green) or fail(red)
• Tests can document faults
• Tests can document code
• Important terminology to remember:
  • Mistake, fault(or defect, or bug), failure, error
  • Oracle

Terminology: Mistake, Fault/Bug, Failure, Error

• Programmer makes a mistake
• Fault(defect, bug) appears in the program
• Program failure occurs during execution(program behaves unexpectedly)
• Error: difference between computed, observed, or measured value or condition and true, specified, or theoretically correct value or condition.

Test input vs. test oracle

Advanced topics in junit

• Assertion patterns
• Parameterized JUnit tests
• Junit theories

Test Driven Development(TDD)

• One of the practices in XP

Kent Beck's rules

• Becks concept of test-driven development centers on two basic rules:
  • Never write a single line of code unless you have a failing automated test
  • Eliminate duplication.

Informal Requirements

If the maintenance contract number provided by the customer is not valid, the item follows the procedure for items not covered by warranty.

Steps in Test Driven Development(TDD)

The iterative process

• Quickly add a test
• Run all tests and see the new one fail.
• Make a little change to code.
• Run all tests and see them all succeed.
• Refactor to remove duplication.

Test First Scenario

• Write test for the newly
  • These test cases will serve as a specification for your implementation
  • These test cases should fail now because the corresponding methods are not implement
  • Write minimal code to make the test pas
  • Add more tests