Introduction to Software Engineering

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

2. 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 Introduction to Software Engineering – ECSE321

3. 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 Introduction to Software Engineering – ECSE321

4. 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 Introduction to Software Engineering – ECSE321

5. 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 Introduction to Software Engineering – ECSE321

6. Review: The Waterfall Model Gather Requirements Testing Specification Design Top down Implementation Integration Bottom up Product 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 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 Introduction to Software Engineering – ECSE321

9. 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 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 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 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! 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 Introduction to Software Engineering – ECSE321

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

15. 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 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 Introduction to Software Engineering – ECSE321

17. Example Accounting Software • Example accounting software • create a named account • list accounts • query balance on an account • delete an account • Task – create user stories Introduction to Software Engineering – ECSE321

18. 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 Introduction to Software Engineering – ECSE321

19. 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 Introduction to Software Engineering – ECSE321

20. 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 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 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. Introduction to Software Engineering – ECSE321

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

24. 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 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) Introduction to Software Engineering – ECSE321

26. 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. 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 Introduction to Software Engineering – ECSE321

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

29. 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 Introduction to Software Engineering – ECSE321

30. 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 Introduction to Software Engineering – ECSE321

31. 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 Introduction to Software Engineering – ECSE321

32. 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 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 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 Introduction to Software Engineering – ECSE321

35. 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 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 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 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. 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 Introduction to Software Engineering – ECSE321

40. 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 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 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 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 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 Introduction to Software Engineering – ECSE321

45. 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 Introduction to Software Engineering – ECSE321

46. 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 Introduction to Software Engineering – ECSE321