a little software engineering: agile software development, practices through values
DESCRIPTION
A little Software Engineering: Agile Software Development, Practices through Values. C Sc 335 Rick Mercer. 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 - PowerPoint PPT PresentationTRANSCRIPT
A little Software Engineering:
Agile Software Development,Practices through Values
C Sc 335Rick 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 1970Understood 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 specificationCoders 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 softwaredisciplined approach to software developmentsuccessful because it emphasizes customer involvement and promotes team worknot a solution looking for a problem59% of 2013 survey respondents use Agile– 83% planned to use agile in the upcoming year
The Agile Manifesto:a statement of values
Process and toolsProcess and toolsIndividuals and interactionsIndividuals and interactions
over
Following a planFollowing a planResponding to changeResponding to change
over
Source: www.agilemanifesto.org
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract negotiation
Customer collaborationCustomer collaboration
over
9
eXtreme Programming (XP)an Agile Process
Values– Communication, Simplicity, Feedback, Courage
Principles– Provide feedback, assume simplicity, make incremental
changes, embrace change, quality workPractices– 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
Costof
change
time
Waterfall
Agile
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 projectDetermining who will do whatUnderstand 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: secondsPair programming feedback: half minutes– Complete all tasks completed in a pair programming mode.
Unit test feedback: few minutesAcceptance 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 needsA 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 overlookedAutomatic testing (JUnit, for example) helps us know that a feature works and it will work after refactoring, additional code, and other changesProvides 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 changeAllows 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, including e-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, seehttp://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 functionalityGoal: 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 programmingWrite 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 teamEverybody is required to improve any portion of bad code s/he seesEveryone has responsibility for the systemIndividual 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 developmentCheckout 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 firstCheck in the system to the common repositoryRepeatYour team should be using Git from command line
– Recommended: do not use the Egit plugin
28
Continuous Integration
Find problems earlyCan see if a change breaks the system more quickly -- while you remember the detailsAdd 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
Coding Standard with Eclipse
30
You may use the Eclipse Standard