1. Introduction to Software Engineering
ECSE-321
Unit 3 – Software Processes – Agile Methods (Part 2)
5/16/2018
Introduction to Software Engineering – ECSE321

2. Introduction to Software Engineering – ECSE321
Agile Methods
Backlash for rigor?
many software development processes (e.g., waterfall) proposed 70s through 90s imposed significant rigor
certain resistance for rigor resulted in counter proposals forming “agile methods”
based on the importance of flexibility in producing software quickly and capably
5/16/2018
Introduction to Software Engineering – ECSE321

3. Introduction to Software Engineering – ECSE321
Agile Manifesto
Value individuals and interactions over processes and tools
Working software more important than comprehensive documentation
Customer collaboration than contract negotiation
Respond to change than stick to a plan
5/16/2018
Introduction to Software Engineering – ECSE321

4. Introduction to Software Engineering – ECSE321
Agile Methods
Goal: quick and continuous delivery of valuable software
Although agile methods are relatively new, many examples have emerged
Extreme Programming is one example
leverages the creativity of programmers
minimize the “administrative” overhead
5/16/2018
Introduction to Software Engineering – ECSE321

5. Introduction to Software Engineering – ECSE321
Extreme Programming
Extreme programming (XP) stresses on four characteristics of agile methods
Communication – continuous exchange of information between customers and developers
Simplicity – go with the simplest design that meet customer requirements
Courage – deliver functionality early and often
Feedback – integrate feedback into various developmental activities
5/16/2018
Introduction to Software Engineering – ECSE321

6. Review: The Waterfall Model
Gather Requirements
Testing
Specification
Design
Top down
Implementation
Integration
Bottom up
Product
5/16/2018
Introduction to Software Engineering – ECSE321

7. Review: Waterfall drawbacks
Major risks
Relies heavily on the ability to accurately estimate requirements at start
Little feedback that comes late – unless customers understand design documents and specifications
Specification problems are found late – as late as integration
Long time to first working version
5/16/2018
Introduction to Software Engineering – ECSE321

8. Extreme Programming Objectives
Minimize “unnecessary” work
Maximize communication and feedback
Make sure that developers do most important work – develop code!
Make system flexible, ready to make any change in requirements
5/16/2018
Introduction to Software Engineering – ECSE321

9. Introduction to Software Engineering – ECSE321
Twelve Practices of XP
On-site customer
working with developers to determine requirements, feedback for testing them
Small releases
system designed to provide functionality as early as possible, subsequent releases
Simple design
keep the design simple anticipating future needs; quick and narrow designs created for complex systems
5/16/2018
Introduction to Software Engineering – ECSE321

10. Twelve Practices of XP (cont)
Writing tests first
forces customers to specify requirements that can be tested; functional tests to verify the customer requirements & unit test to verify implementation
Collective ownership
any developer can make changes to any part of the code
Continuous integration
small increments are delivered quickly
5/16/2018
Introduction to Software Engineering – ECSE321

11. Twelve Practices of XP (cont)
The planning game
users write “stories” (2 to 3 lines) on system requirements; stories are prioritize requirements, splitting, and merging stories until consensus; planners generate map of each release
Pair programming
one person codes and other observes; pair switch roles
Metaphor
agreement on common vision with appropriate terminology
5/16/2018
Introduction to Software Engineering – ECSE321

12. Twelve Practices of XP (cont)
Refactoring
refactoring can affect design and code without changing external system behaviour
Sustainable pace
fatigue can produce errors; 40 hours per week
Coding standards
XP advocates precise coding standards so that the body of code looks like written by a single person!
5/16/2018
Introduction to Software Engineering – ECSE321

13. Extreme Programming Process
Short cycle (2 weeks)
Meet with client to elicit requirements
user stories + acceptance tests
Planning game
break stories into tasks, estimate effort
client prioritizes stories to do first
Implementation
write tests first
simplest possible design to the tests
code in pairs
occasionally refactor code
Evaluate progress and reiterate from step 1
5/16/2018
Introduction to Software Engineering – ECSE321

14. Introduction to Software Engineering – ECSE321
XP Process
time
Waterfall
Iterative
Extreme
Analyze
Design
Implement
Test
Analyze
Design
Implement
Test
Analyze
Design
Implement
Test
scope
5/16/2018
Introduction to Software Engineering – ECSE321

15. Introduction to Software Engineering – ECSE321
XP Customer
Expert customer is part of the team
on site, available constantly
XP principles: communication and feedback
make sure system built is what customer wants
Customer involved in all stages
clarifies the requirements
negotiates with team on what to do next
writes and runs acceptance tests
constantly evaluates intermediate versions
5/16/2018
Introduction to Software Engineering – ECSE321

16. Planning Game: User stories
Write on index cards
meaningful titles
short customer-centric requirements
Focus on “what” not “why” or “how”
Use customer language
customer must be able to check if story is complete
No need to have all stories in first version
5/16/2018
Introduction to Software Engineering – ECSE321

17. Example Accounting Software
create a named account
list accounts
query balance on an account
delete an account
Task – create user stories
5/16/2018
Introduction to Software Engineering – ECSE321

18. Introduction to Software Engineering – ECSE321
User stories
Title: Create Account
Description: I can create an account with a given name
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
5/16/2018
Introduction to Software Engineering – ECSE321

19. Introduction to Software Engineering – ECSE321
User stories
How is the list ordered?
Title: Create Account
Description: I can create an account with a given name
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
5/16/2018
Introduction to Software Engineering – ECSE321

20. Introduction to Software Engineering – ECSE321
User stories
How is the list ordered?
Title: Create Account
Description: I can create an account with a given name
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
5/16/2018
Introduction to Software Engineering – ECSE321

21. User stories Title: Create Account
Description: I can create an account with a given name
Title: List Accounts
Description: I can get a list of all accounts. I can get an alphabetical list of all accounts.
Can I delete if 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
5/16/2018
Introduction to Software Engineering – ECSE321

22. User stories Title: Create Account
Description: I can create an account with a given name
Title: List Accounts
Description: I can get a list of all accounts. I can get an alphabetical list of all accounts.
Can I delete if 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 if the balance is zero.
5/16/2018
Introduction to Software Engineering – ECSE321

23. Introduction to Software Engineering – ECSE321
User story?
Title: User AJAX for UI
Description: The user interface will use AJAX technologies to provide a cool online experience.
5/16/2018
Introduction to Software Engineering – ECSE321

24. Introduction to Software Engineering – ECSE321
User story?
Title: User AJAX for UI
Description: The user interface will use AJAX technologies to provide a cool online experience.
Not a user story
5/16/2018
Introduction to Software Engineering – ECSE321

25. Customer Acceptance Tests
Customer must describe how the user stories will be tested
with concrete data examples
associated with (one or more) user stories
Tests would make the user stories more formal (at least verifiable)
5/16/2018
Introduction to Software Engineering – ECSE321

26. Introduction to Software Engineering – ECSE321
User stories
Title: Create Account
Description: I can create an account with a given name
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 if the balance is zero.
5/16/2018
Introduction to Software Engineering – ECSE321

27. Customer Accounting Tests
Tests are associated with one or more stories
If I create an account “savings” and “checking” and ask for the list of accounts I must get “savings” and “checking”
If I now try to create “checking” again, I must get an error
If I now query the balance of “checking”, I must get 0.
If I try to delete “stocks”, I must get an error
If I delete “checking”, it should not appear in the listing of accounts
5/16/2018
Introduction to Software Engineering – ECSE321

28. Automate Acceptance Tests
Customer can write and later (re)run tests
Tests should be automated
5/16/2018
Introduction to Software Engineering – ECSE321

29. Introduction to Software Engineering – ECSE321
Tasks
Story: a customer-centric description of what needs to be done
Task: what should be done accomplish a story from developer point-of-view
Example
Story: “I can create an account with a name”
Tasks: “ask the user for the account name”
“check to see if account already exists”
“create an empty account”
Breakdown a story to estimate effort accurately
Validate breakdown with the customer
5/16/2018
Introduction to Software Engineering – ECSE321

30. Introduction to Software Engineering – ECSE321
Tasks (contd)
Team assigns costs to tasks – relative weighting of tasks
Care only about relative weights
Use abstract “units” for weights
Smallest task gets 1 unit
Developers are bound to have experience doing tasks
Developers can assign/estimate units by bidding
5/16/2018
Introduction to Software Engineering – ECSE321

31. Introduction to Software Engineering – ECSE321
Planning Game
Select and
Estimate
Tasks
Read
Story Cards
Write
Task
Cards
Unclaimed Tasks
Select and
Estimate
Tasks
Programmer 1
Programmer 2
Programmer 3
Accepted
Tasks
5/16/2018
Introduction to Software Engineering – ECSE321

32. Introduction to Software Engineering – ECSE321
Planning Game (contd)
Customer chooses the important stories
Development team
breaks stories into tasks
bids on tasks – we know the load taken by each subteam (programmer)
Pick more tasks
Customer could re-prioritize stories
Repeat until all stories are picked
5/16/2018
Introduction to Software Engineering – ECSE321

33. Test-driven Development
Write unit tests before implementing tasks
Unit test: concentrate on one module
Testing first:
forces simplicity – your objective is to meet the test – optimization waits
clarifies the task – makes the task more concrete because a realization to meet the test is necessary
acts as useful documentation – exposes the intent of the developer
5/16/2018
Introduction to Software Engineering – ECSE321

34. Test-driven Development
Fail a unit test
fix the code to pass the test
Fail an acceptance test (user story)
not enough tests
add more tests, fix code to meet new tests
5/16/2018
Introduction to Software Engineering – ECSE321

35. Introduction to Software Engineering – ECSE321
Simplicity
Just-in-time design
design and implement based on current understanding
no need to make it futureproof
No premature optimization
Even in big systems there are useful simple versions
5/16/2018
Introduction to Software Engineering – ECSE321

36. Refactoring: Improving the Code design
Make the code easier to read/use/modify
change how “code” does a particular function
Why?
incremental feature introduction might outgrow initial design
expected because initial design was not futureproof
5/16/2018
Introduction to Software Engineering – ECSE321

37. Refactoring: Remove duplicate code
Why?
Duplicate elimination helps
code understanding later
makes future changes easier
code maintenance becomes easier – less number of lines to maintain
5/16/2018
Introduction to Software Engineering – ECSE321

38. Refactoring: Name Changes
Why?
a name should suggest what a method does and how it should be used
With new features additions
functionality provided by some methods can change over time
such methods should be prime candidates for name change.
5/16/2018
Introduction to Software Engineering – ECSE321

39. Continuous Integration
Integrate your work after each task
start with current official “release”
once task is completed, integrate changes (task) with current official release
All unit tests must run after integration
5/16/2018
Introduction to Software Engineering – ECSE321

40. Introduction to Software Engineering – ECSE321
XP: Pair programming
Pilot and copilot metaphor
Or driver and navigator (e.g., in rally driving)
Pilot types, copilot monitors high-level issues
simplicity, integration with other components
Disagreements can point to early design problems
Pairs shuffled periodically
5/16/2018
Introduction to Software Engineering – ECSE321

41. Benefits of Pair Programming
Results in better code
instant and complete and pleasant code review
copilot can think about big picture
Reduces risk
collective understanding of design/code
Improves focus and productivity
instant source of advice
Knowledge and skill migration
good habits spread
5/16/2018
Introduction to Software Engineering – ECSE321

42. Why Some Programmers Resist Pairing?
“Will slow me down”
It is stressful to relate to people all the time
Need time alone to figure things out
Afraid to show you are not a genius
5/16/2018
Introduction to Software Engineering – ECSE321

43. Why Some Managers Resist Pairing?
Myth: Inefficient use of personal
only true if typing is the bottleneck of programming!
Resistance from developers
find people who want to pair
5/16/2018
Introduction to Software Engineering – ECSE321

44. Evaluation and Planning
Run acceptance tests
Assess what was completed
How many stories completed?
Discuss problems that came up
Both technical and team issues
Compute the speed of the subteams
Re-estimate remaining user stories
Plan with the client next iteration
5/16/2018
Introduction to Software Engineering – ECSE321

45. Introduction to Software Engineering – ECSE321
Why XP is different?
No specialized analysts, architects, programmers
Every XP developer participates in all critical activities
No complete up-front analysis and design
start with quick analysis and design
team continues to analysis and design decisions throughout development
5/16/2018
Introduction to Software Engineering – ECSE321

46. Introduction to Software Engineering – ECSE321
When to (Not) use XP?
Use for
Projects done in small teams (2-10 people)
Projects with requirements that are prone to change
Have a customer available
Not use when
Requirements are truly known and fixed
Cost of late changes is very high
Customer is not available
5/16/2018
Introduction to Software Engineering – ECSE321