Introduction to Software Engineering
ECSE-321
Unit 3 – Software Processes – Agile Methods (Part 2)
04/21/23 Unit 2 - Conventions and practices/1Introduction 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
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /2
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
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /3
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
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /4
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
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /5
Review: The Waterfall Model
04/21/23 Introduction to Software Engineering – ECSE321 Unit 2 - Conventions and practices/6
Gather RequirementsGather Requirements
SpecificationSpecification
DesignDesign
ImplementationImplementation
IntegrationIntegration
ProductProduct
Top down
Bottom up
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
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /7
Extreme Programming Objectives
Minimize “unnecessary” workMaximize communication and feedbackMake sure that developers do most
important work – develop code!Make system flexible, ready to make any
change in requirements
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /8
Twelve Practices of XP
On-site customer● working with developers to determine
requirements, feedback for testing themSmall 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
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /9
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 codeContinuous integration
● small increments are delivered quickly
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /10
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
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /11
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!
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /12
Extreme Programming Process
Short cycle (2 weeks)1. Meet with client to elicit requirements
● user stories + acceptance tests2. Planning game
● break stories into tasks, estimate effort● client prioritizes stories to do first
3. Implementation● write tests first● simplest possible design to the tests● code in pairs● occasionally refactor code
4. Evaluate progress and reiterate from step 104/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /13
XP Process
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /14
Analyze
Design
Implement
Test
Waterfall
scope
Analyze
Design
Implement
Test
Analyze
Design
Implement
Test
Iterative Extreme
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
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /15
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
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /16
Example Accounting Software
Example accounting software● create a named account
● list accounts
● query balance on an account
● delete an account
Task – create user stories
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /17
User stories
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /18
Title: Create AccountDescription: I can create an account with a given name
Title: List AccountsDescription: I can get a list of all accounts
Title: Query Account BalanceDescription: I can query account balance
Title: Delete AccountDescription: I can delete a named account
User stories
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /19
Title: Create AccountDescription: I can create an account with a given name
Title: List AccountsDescription: I can get a list of all accounts
Title: Query Account BalanceDescription: I can query account balance
Title: Delete AccountDescription: I can delete a named account
How is the list ordered?
User stories
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /20
Title: Create AccountDescription: I can create an account with a given name
Title: List AccountsDescription: I can get a list of all accounts. I can get an alphabetical list of all accounts.
Title: Query Account BalanceDescription: I can query account balance
Title: Delete AccountDescription: I can delete a named account
How is the list ordered?
User stories
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /21
Title: Create AccountDescription: I can create an account with a given name
Title: List AccountsDescription: I can get a list of all accounts. I can get an alphabetical list of all accounts.
Title: Query Account BalanceDescription: I can query account balance
Title: Delete AccountDescription: I can delete a named account
Can I delete if a balance is not zero?
User stories
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /22
Title: Create AccountDescription: I can create an account with a given name
Title: List AccountsDescription: I can get a list of all accounts. I can get an alphabetical list of all accounts.
Title: Query Account BalanceDescription: I can query account balance
Title: Delete AccountDescription: I can delete a named account if the balance is zero.
Can I delete if a balance is not zero?
User story?
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /23
Title: User AJAX for UIDescription: The user interface will use AJAX technologies to provide a cool online experience.
User story?
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /24
Title: User AJAX for UIDescription: The user interface will use AJAX technologies to provide a cool online experience.
Not a user story
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)
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /25
User stories
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /26
Title: Create AccountDescription: I can create an account with a given name
Title: List AccountsDescription: I can get a list of all accounts. I can get an alphabetical list of all accounts.
Title: Query Account BalanceDescription: I can query account balance
Title: Delete AccountDescription: I can delete a named account if the balance is zero.
Customer Accounting Tests
Tests are associated with one or more stories1. If I create an account “savings” and “checking” and
ask for the list of accounts I must get “savings” and “checking”
2. If I now try to create “checking” again, I must get an error
3. If I now query the balance of “checking”, I must get 0.
4. If I try to delete “stocks”, I must get an error5. If I delete “checking”, it should not appear in the
listing of accounts
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /27
Automate Acceptance Tests
Customer can write and later (re)run testsTests should be automated
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /28
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 accuratelyValidate breakdown with the customer
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /29
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
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /30
Select andEstimate
Tasks
Select andEstimate
Tasks
Planning Game
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /31
ReadStory Cards
ReadStory Cards
WriteTaskCards
WriteTaskCards
Unclaimed Tasks
Unclaimed Tasks
Select andEstimate
Tasks
Select andEstimate
Tasks
Programmer1
Programmer1
Programmer2
Programmer2
Programmer3
Programmer3
AcceptedTasks
Planning Game (contd)
Customer chooses the important storiesDevelopment team
● breaks stories into tasks
● bids on tasks – we know the load taken by each subteam (programmer)
Pick more tasksCustomer could re-prioritize storiesRepeat until all stories are picked
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /32
Test-driven Development
Write unit tests before implementing tasksUnit test: concentrate on one moduleTesting 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
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /33
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
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /34
Simplicity
Just-in-time design● design and implement based on current
understanding
● no need to make it futureproof
No premature optimizationEven in big systems there are useful
simple versions
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /35
Refactoring: Improving the Code designMake 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
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /36
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
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /37
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.
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /38
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
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /39
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
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /40
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
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /41
Why Some Programmers Resist Pairing?“Will slow me down”It is stressful to relate to people all the
timeNeed time alone to figure things outAfraid to show you are not a genius
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /42
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
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /43
Evaluation and Planning
Run acceptance testsAssess what was completed
● How many stories completed?
Discuss problems that came up● Both technical and team issues
Compute the speed of the subteamsRe-estimate remaining user storiesPlan with the client next iteration04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /44
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
04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /45
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 available04/21/23 Introduction to Software Engineering – ECSE321 Unit 3 – Software Processes /46
