Review: The Waterfall Model

Gather Requirements

Agile Processes: Extreme Programming

CS169 Lecture 3
(many slides courtesy of Aiken, Bodik, Johnson, Necula)

Specification Design Implementation Integration Testing

Prof. Sen CS 169 Lecture 3

Prof. Sen CS 169 Lecture 3

Product

Review: Waterfall drawbacks

The major risks are:
Relies heavily on being able to accurately assess requirements at the start Little feedback from users until very late
Unless they understand specification and design documents

Iterative Process: Advantages Find problems sooner

Get early feedback from users Get early feedback on whether spec/design are feasible

Problems in the specification may be found very late

Coding or integration

More quantifiable than waterfall

When build 3 of 4 is done, product is 75% complete What percentage have we completed at the implementation stage of the waterfall model?

Whole process can take a long time before the first working version is seen

Prof. Sen CS 169 Lecture 3

Prof. Sen CS 169 Lecture 2

Iterative Process: Disadvantages Main risk is making a major mistake in requirements, spec, or design
Because we dont invest as much time before build 1 Begin coding before problem is fully understood

In Practice Most consumer software development uses the iterative model

Daily builds System is always working Microsoft is a well-known example

Trade this off against the risks of being slow

Often better to get something working and get feedback on that rather than study problem in the abstract

Many systems that are hard to test use something more like a waterfall model
E.g., unmanned space probes

Prof. Sen CS 169 Lecture 2

Prof. Sen CS 169 Lecture 2

Extreme Programming Waterfall model inspired by civil engineering Civil engineering metaphor is not perfect
Software is more organic than concrete You grow the software to meet changing requirements

Goals Minimize unnecessary work Maximize communication and feedback Make sure that developers do most important work Make system flexible, ready to meet any change in requirements

Extreme Programming (XP) addresses this

A version of the iterative model discussed before Recommended reading: Extreme Software Engineering. A Hands-On Approach by D. Steinberg and D. Palmer
Prof. Sen CS 169 Lecture 3 7

Prof. Sen CS 169 Lecture 3

XP Practices
On-site customer The Planning Game Small releases Testing Simple design Refactoring Metaphor Pair programming Collective ownership Continuous integration 40-hour week Coding standards

XP Process
Short cycle (2 weeks): 1. Meet with client to elicit requirements 2. Planning game
User stories + acceptance tests Break stories into tasks, estimate cost Client prioritizes stories to do first Write programmer tests first Simplest possible design to pass the tests Code in pairs Occasionally refactor the code

3. Implementation

4. Evaluate progress and reiterate from step 1

Prof. Sen CS 169 Lecture 3 9 Prof. Sen CS 169 Lecture 3 10

Extreme Programming (XP) XP: like iterative but taken to the extreme

XP Customer Expert customer is part of the team

On site, available constantly XP principles: communication and feedback Make sure we build what the client wants

Time

Waterfall Test Implement Design Analyze

Iterative

XP

Customer involved actively in all stages:

Clarifies the requirements Negotiates with the team what to do next Writes and runs acceptance tests Constantly evaluates intermediate versions
Prof. Sen CS 169 Lecture 3 12

Scope

Prof. Sen CS 169 Lecture 3

11

Administrivia Grading
20% on homework 30% on mid-term exam 50% on project (more info later)

The Planning Game: User Stories Write on index cards

meaningful title short (customer-centered) description

Use curve for grading

Average is B

Focus on what not the why or how Uses client language

Client must be able to test if a story is completed

Mid-term exam in class on 4/12. No finals. Your final demo, report, and presentation will be your finals.
Prof. Sen CS 169 Lecture 3 13

No need to have all stories in first iteration

Prof. Sen CS 169 Lecture 3 14

Accounting Software I need an accounting software using which I can create a named account, list accounts, query the account balance, and delete an account. Analyze the CEOs statement and create some user stories

User Stories
Title: Create Account Description: I can create a named account Title: List Accounts Description: I can get a list of all accounts.

Title: Query Account Balance Description: I can query account balance.

Title: Delete Account Description: I can delete a named account

Prof. Sen CS 169 Lecture 3

15

Prof. Sen CS 169 Lecture 3

16

User Stories
Title: Create Account Description: I can create a named account

How is the list ordered?

Title: List Accounts Description: I can get a list of all accounts.

User Stories
Title: Create Account Description: I can create a named account

How is the list ordered?

Title: List Accounts Description: I can get a list of all accounts. I can get an alphabetical list of all accounts.

Title: Query Account Balance Description: I can query account balance.

Title: Delete Account Description: I can delete a named account

Title: Query Account Balance Description: I can query account balance.

Title: Delete Account Description: I can delete a named account

Prof. Sen CS 169 Lecture 3

17

Prof. Sen CS 169 Lecture 3

18

User Stories
Title: Create Account Description: I can create a named account Title: List Accounts Description: I can get a list of all accounts. I can get an alphabetical list of allCan I delete if accounts.

User Stories
Title: Create Account Description: I can create a named account Title: List Accounts Description: I can get a list of all accounts. I can get an alphabetical list of allCan I delete if accounts.

a balance is not zero?

a balance is not zero?

Title: Query Account Balance Description: I can query account balance.

Title: Delete Account Description: I can delete a named account

Title: Query Account Balance Description: I can query account balance.

Title: Delete Account Description: I can delete a named account if the balance is zero.

Prof. Sen CS 169 Lecture 3

19

Prof. Sen CS 169 Lecture 3

20

User Story?

User Story?

Title: Use AJAX for UI Description: The user interface will use AJAX technologies to provide a cool and slick online experience.

Title: Use AJAX for UI Description: The user interface will use AJAX technologies to provide a cool and slick online experience.

Not a user story

Prof. Sen CS 169 Lecture 3

21

Prof. Sen CS 169 Lecture 3

22

Customer Acceptance Tests Client must describe how the user stories will be tested
With concrete data examples, Associated with (one or more) user stories

User Stories
Title: Create Account Description: I can create a named account Title: List Accounts Description: I can get a list of all accounts. I can get an alphabetical list of all accounts.

Concrete expressions of user stories

Title: Query Account Balance Description: I can query account balance.

Title: Delete Account Description: I can delete a named account if the balance is zero.

Prof. Sen CS 169 Lecture 3

23

Prof. Sen CS 169 Lecture 3

24

Example: Accounting Customer Tests

Tests are associated with (one or more) stories 1. If I create an account savings, then another called checking, and I ask for the list of accounts I must obtain: checking, savings 2. If I now try to create checking again, I get an error 3. If now I query the balance of checking, I must get 0. 4. If I try to delete stocks, I get an error 5. If I delete checking, it should not appear in the new listing of accounts
Prof. Sen CS 169 Lecture 3 25

Automate Acceptance Tests Customer can write and later (re)run tests
E.g., customer writes an XML table with data examples, developers write tool to interpret table

Tests should be automated

To ensure they are run after each release

Prof. Sen CS 169 Lecture 3

26

XP Planning Game

Tasks
Each story is broken into tasks
To split the work and to improve cost estimates

Story: customer-centered description Task: developer-centered description Example:

Story: I can create named accounts Tasks: ask the user the name of the account check to see if the account already exists create an empty account

Break down only as much as needed to estimate cost Validate the breakdown of stories into tasks with the customer
Prof. Sen CS 169 Lecture 3 27 Prof. Sen CS 169 Lecture 3 28

Tasks If a story has too many tasks: break it down Team assigns cost to tasks
We care about relative cost of task/stories Use abstract units (as opposed to hours, days) Decide what is the smallest task, and assign it 1 unit Experience will tell us how much a unit is Developers can assign/estimate units by bidding: I can do this task in 2 units

Play the Planning Game

Prof. Sen CS 169 Lecture 3

29

Prof. Sen CS 169 Lecture 3

30

Planning Game Customer chooses the important stories for the next release Development team bids on tasks
After first iteration, we know the speed (units/ week) for each subteam

Test-driven development Write unit tests before implementing tasks Unit test: concentrate on one module
Start by breaking acceptance tests into units

Pick tasks => find completion date Pick completion date, pick stories until you fill the budget Customer might have to re-prioritize stories
Prof. Sen CS 169 Lecture 3 31

Example of a test

addAccount(checking); if(balance(checking) != 0) throw ; try { addAccount(checking); throw ; Test both good and } catch(DuplicateAccount e) { }; bad behavior
Prof. Sen CS 169 Lecture 3 32

Think about names and calling conventions

Why Write Tests First? Testing-first clarifies the task at hand Testing forces simplicity
Forces you to think in concrete terms Helps identify and focus on corner cases Your only goal (now) is to pass the test Fight premature optimization Exposes (completely) the programmers intent Courage to refactor code Courage to change code

Test-Driven Development. Bug Fixes Fail a unit test

Fix the code to pass the test

Fail an acceptance test (user story)

Means that there arent enough user tests Add a user test, then fix the code to pass the test

Tests act as useful documentation

Fail on beta-testing
Make one or more unit tests from failing scenario

Testing increases confidence in the code

Always write code to fix tests

Ensures that you will have a solid test suite
33 Prof. Sen CS 169 Lecture 3 34

Prof. Sen CS 169 Lecture 3

Simplicity (KISS) Just-in-time design

design and implement what you know right now; dont worry too much about future design decisions

Refactoring: Improving the Design of Code Make the code easier to read/use/modify
Change how code does something

Why?
Incremental feature extension might outgrow the initial design Expected because of lack of extensive early design

No premature optimization
You are not going to need it (YAGNI)

In every big system there is a simple one waiting to get out

Prof. Sen CS 169 Lecture 3

35

Prof. Sen CS 169 Lecture 3

36

Refactoring: Remove Duplicated Code Why? Easier to change, understand Inside a single method: move code outside conditionals
if() { c1; c2 } else { c1; c3} c1; if() { c2 } else { c3 }

Refactoring: Change Names Why?

A name should suggest what the method does and how it should be used

Examples:
moveRightIfCan, moveRight, canMoveRight

In several methods: create new methods Almost duplicate code

balance + 5 and balance x int incrBalance(int what) { return balance + what; } incrBalance(5) and incrBalance(- x)
Prof. Sen CS 169 Lecture 3 37

Meth1: rename the method, then fix compiler errors

Drawback: many edits until you can re-run tests

Meth2: copy method with new name, make old one

call the new one, slowly change references Advantage: can run tests continuously
Prof. Sen CS 169 Lecture 3

38

Refactoring and Regression Testing

Comprehensive suite needed for fearless refactoring Only refactor working code

Continuous Integration Integrate your work after each task.

Start with official release Once task is completed, integrate changes with current official release.

Do not refactor in the middle of implementing a feature

Plan your refactoring to allow frequent regression tests Modern tools provide help with refactoring Recommended book: Martin Fowlers Refactoring
Prof. Sen CS 169 Lecture 3 39

All unit tests must run after integration.

Prof. Sen CS 169 Lecture 3

40

XP: Pair programming Pilot and copilot metaphor

Or driver and navigator

Pair programming

Pilot types, copilot monitors high-level issues

simplicity, integration with other components, assumptions being made implicitly

Disagreements point early to design problems Pairs are shuffled periodically

Prof. Sen CS 169 Lecture 3

41

Prof. Sen CS 169 Lecture 3

42

Benefits of Pair Programming Results in better code

instant and complete and pleasant code review copilot can think about big-picture

Why Some Programmers Resist Pairing ? Will slow me down

Even the best hacker can learn something from even the lowliest programmer

Reduces risk
collective understanding of design/code

Afraid to show you are not a genius

Neither is your partner Best way to learn

Improves focus and productivity

instant source of advice

Knowledge and skill migration

good habits spread
Prof. Sen CS 169 Lecture 3 43 Prof. Sen CS 169 Lecture 3 44

Why Some Managers Resist Pairing? Myth: Inefficient use of personnel

That would be true if the most time consuming part of programming was typing ! 15% increase in dev. cost, and same decrease in bugs
2 individuals: 50 loc/h each, 1 bug/33 loc 1 team: 80 loc/h, 1 bug/40 loc 1 bug fix costs 10 hours 50kloc program 2 individuals: 1000 devel + 15000 bug fix 50kloc program 1 team: 1250 devel + 12500 bug fix

Evaluation and Planning Run acceptance tests Assess what was completed
How many stories ?

Discuss problems that came up

Both technical and team issues

Resistance from developers

Ask them to experiment for a short time Find people who want to pair
Prof. Sen CS 169 Lecture 3 45

Compute the speed of the team Re-estimate remaining user stories Plan with the client next iteration

Prof. Sen CS 169 Lecture 3

46

XP Practices
On-site customer The Planning Game Small releases Testing Simple design Refactoring Metaphor Pair programming Collective ownership Continuous integration 40-hour week Coding standards

Whats Different About XP No specialized analysts, architects, programmers, testers, and integrators
every XP programmer participates in all of these critical activities every day.

No complete up-front analysis and design

start with a quick analysis of the system team continues to make analysis and design decisions throughout development.

Prof. Sen CS 169 Lecture 3

47

Prof. Sen CS 169 Lecture 3

48

Whats Different About XP Develop infrastructure and frameworks as you develop your application
not up-front quickly delivering business value is the driver of XP projects.

When to (Not) Use XP Use for:

A dynamic project done in small teams (2-10 people) Projects with requirements prone to change Have a customer available

Do not use when:

Requirements are truly known and fixed Cost of late changes is very high Your customer is not available (e.g., space probe)

Prof. Sen CS 169 Lecture 3

49

Prof. Sen CS 169 Lecture 3

50

Recommended Approach in This Class Extreme Classical Classical: Extreme

Conclusion Extreme Programming is an incremental software process designed to cope with change With XP you never miss a deadline; you just deliver less content

Staged waterfall development Generation of project documentation as you go XP planning game to move from customer requirements (user stories) to design specification Test-driven development Refactoring Continuous system integration Pair-programming (encouraged)
Prof. Sen CS 169 Lecture 3 51

Prof. Sen CS 169 Lecture 3

52