1 / 30

A little Software Engineering: Agile Software Development, Practices through Values

Learn about agile software development practices and values that can help you complete a final project on time with better results. Discover the difference between waterfall and agile methodologies, and explore the benefits of agile practices such as communication, feedback, and customer collaboration. This guide will provide you with valuable insights and tools to improve your software development process.

pattonm
Download Presentation

A little Software Engineering: Agile Software Development, Practices through Values

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. A little Software Engineering:Agile Software Development,Practices through Values C Sc 335 Rick Mercer

  2. Goal and Outline • Main Goal: • Suggest practices, values, and some process for completing a final project on time that is better than any one person could do it in in four times the time • Outline • Distinguish Waterfall (plan driven) from Agile • Practices and Values of quality software development

  3. Waterfall Model • Waterfall was described by 1970 • Understood as • finish each phase • don’t proceed till done • W. W. Roycecriticized this • proposed an iterative approach

  4. Became Popular • Management (usually software ignorant) like phases • to easily set deadlines • Customers provide all requirements • Analysts translate requirements into specification • Coders implement the specification • Reviews ensure the specification is met • Testing is performed by testers (not the devs) (QA) • Maintenance means modifying as little as possible • old code is good code • Change is hard (and costly)

  5. To waterfall or not • Waterfall became popular, and for no good reasons • This process is still is used a lot • Craig Larman's book [1] provides proof that waterfall is a terrible way to develop software • In his study, 87% of all projects failed • The waterfall process was the "single largest contributing factor for failure, being cited in 81% of the projects as the number one problem." [1] Agile and Iterative Development: a Manager's Guide, Addison-Wesley Professional, 2003

  6. A Spiral Approach • Dr. Barry Boehm proposed a spiral approach

  7. Agile Software Development • set of practices to produce high-quality software • disciplined approach to software development • successful because it emphasizes customer involvement and promotes team work • not a solution looking for a problem • 59% of 2013 survey respondents use Agile • 83% planned to use agile in the upcoming year

  8. Individuals and interactions Responding to change Working software Customer collaboration Following a plan Comprehensive documentation Contract negotiation Process and tools over over over over The Agile Manifesto:a statement of values Source: www.agilemanifesto.org

  9. eXtreme Programming (XP)an Agile Process • Values • Communication, Simplicity, Feedback, Courage • Principles • Provide feedback, assume simplicity, make incremental changes, embrace change, quality work • Practices • Planning game, small releases, simple designs, automated testing, continuous integration, refactoring, pair programming, collective ownership, continuous integration, on-site customer, coding standard

  10. Cost of change Waterfall Cost of change Agile time

  11. Cost of the Project • Paraphrasing from two companies I've talked to (probably many more) • When we bid projects, we charge $X for doing it Waterfall and $X/2 for doing it Agile

  12. Agile Practices: The Planning Game • The planning game involves user stories • Short descriptions of desired features • Provide value to customer • Testable (do we have that feature two weeks in?) • Clients write stories and prioritize them • In 335, SLs wrote the requirements, you prioritize • Developers estimate how long a story takes • If you are so inclined, estimate each requirement

  13. Values: Communication • Simply talking about the project • Determining who will do what • Understand Requirements • Write user stories to represent what the system will do • Analysis & Design sessions • Happening whenever the team is together

  14. Values: Communication • Pair programming • A good thing • Iteration planning • What to do in the next iteration • Retrospectives, for example what do we • Stop doing • Continue doing • Start doing

  15. Values: Feedback • Feedback very important • Small Iterations • Pair programming • Constant code review (pair programming) • Continuous integration (add often to the build—sync your code with the system) • Check out, run all test including your new tests and code, if all pass, check in the updated system • Automated unit tests (JUnit)

  16. Values: Feedback • Compiler feedback: seconds • Pair programming feedback: half minutes • Complete all tasks completed in a pair programming mode. • Unit test feedback: few minutes • Acceptance testing: Each Iteration • Your PM has accepted Iteration 1 or told you what’s missing

  17. Practices: On-site customer • Many software projects fail because they do not deliver software that meets needs • A real client should be part of the team • Defines / decides the needs • Answers questions and resolves issues • Prioritizes features • Helps prevents devs from making decisions like: "They probably wanted us to ....” • Consider your PM playing this role

  18. Practices: Simple design • The “right” design • Runs all tests • No code duplication, No code duplication, No code duplication • Composed methods

  19. Practices: Testing • Software should be tested, but it is often spotty or overlooked • Automatic testing (JUnit, for example) helps us know that a feature works and it will work after refactoring, additional code, and other changes • Provides confidence in the program

  20. Testing • Write tests at the same time as production code • Unit tests  developer • Feature/acceptance tests  grader in 335 • Don't need a test for every method (but why not?) • Testing can be used to drive development and design of code • But it helps to have an overall architecture first (see your UML class diagram, which is subject to change • Allows for regression testing • Did my change break previously working code? • If well-tested, you see the red bar when you break your code

  21. Regression Testing • Regression Testing • re-testing of a previously tested program following modification to ensure that faults have not been introduced or uncovered as a result of changes. • Regression tests are designed for repeatability, and are often used when testing a second or later version of the system under test • Regression testing can be carried out on all applications, includinge-Commerce and web-based systems

  22. Testing • Strong emphasis on regression testing • Unit tests need to execute all the time • Unit tests pass 100% • Other testing frameworks include • SUnit (Smalltalk), HttpUnit (WebApps), AceUnit (C), CPPUnit (C++), PyUnit (Python) • For a complete list, see http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks

  23. Can't unit test always • Won’t have unit tests for • GUIs: There are testing frameworks to simulate and test user interaction, but not this course • Just added to WebCat • Network, use visual inspection while running • Views, animation, drawing: visually inspect • this is system verification too • Randomness: Some strategies might have some randomness, which can be hard to work with • Use “tournaments” to see which AI wins, print restults

  24. Practices: Refactoring • Restructure code without changing the functionality • Goal: Keep design simple • Change bad design when you find it • Remove “dead” code • Examples at Martin Fowler's Web site: http://www.refactoring.com/see online catalog

  25. Practices: Pair programming • Write production code with 2 people on one machine • Person 1: Implements the method (Driver) • Person 2: Thinks strategically about potential improvements, test cases, issues (Observer or Navigator) • Pairs change all the time. Has advantages such as • No single expert on any part of the system • Continuous code reviews, fewer defects • Cheaper in the long run, and more fun • Issues with Pair Programming: • Not all people like it, not everyone gets along • Pairs need to be able to work together (tough in college) • Requires tolerance, acceptance, showers, no bad breath

  26. Practices: Collective ownership • All code can be changed by anybody on the team • Everybody is required to improve any portion of bad code s/he sees • Everyone has responsibility for the system • Individual code ownership tends to create "experts", the "experts" tend to create difficult team situations • Every year in 335... • What would you do? • A team member does not like curly brace line up the other 3 do. Should we go with 1, 3, or negotiate?

  27. Practices: Continuous integration • Integration happens after a few hours of development • Checkout repo with your changes, • which may require handling conflicts of two people have modified the same class or method • Make sure all tests pass (green bar) • In case of errors: • Do not put changes into the repo, fix them first • Check in the system to the common repository • Repeat • Your team should be using Git from command line • Recommended: do not use the Egit plugin

  28. Continuous Integration • Find problems early • Can see if a change breaks the system more quickly -- while you remember the details • Add to the build on BitBucket in small increments • Every few hours, or • after any new feature, or • When it feels right • Nice to have all 4 in the same room so everyone knows

  29. Practices: Coding standards • Coding Standard • Naming conventions and style • Least amount of work possible: Code should exist once and only once • Everyone always use Java 7 always • Team has to adopt a coding standard • Makes it easier to understand other people’s code • Avoids code changes due to syntactic preferences • You get to fight over curly brace placement

  30. Coding Standard with Eclipse You may use the Eclipse Standard

More Related