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 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

Waterfall Became Popular

Management (usually software ignorant) like phases – to easily set deadlines

Customers provide all requirements Analysts translate requirements into specificationCoders implement the specification 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 for few good reasons– But 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 this year

The Agile Manifesto:a statement of values

Process and toolsIndividuals and interactions

over

Following a planResponding to change

over

That is, while there is value in the items on the right, we value the items

on the left more.

Comprehensive documentation

Working software over

Contract negotiation

Customer 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 software development companiesWhen 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 (will we have that feature two weeks from now?)

Clients write requirements (user stories) and prioritize– In 335, this planning was done last week

Break up these requirements into tasks – Specific things to do: Design the, Write code to, Write test

plan, Meet with, Do a spike for shortest path, …

Match tasks to team member(s)

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. You are doing code review!

Iteration planning– What to do in the next iteration. We have 2 iterations

Retrospectives, for example what should the team– Stop doing– Continue doing– Start doing

15

Values: Feedback

• Small Iterations• Pair programming• Constant code review (pair programming)• Continuous integration (add often to the build—

sync your code with the system)– Pull the project from GitHub, run all tests including

your new tests and code, if all pass, commit locally, and push your project

• 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– For a better grade, first have your team ensure you have all

requirements working

17

Practices: Simple design

Runs all testsNo code duplication, No code duplication, No code duplicationComposed methods– More on this later when we talk about refactoring

18

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

19

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 methodTesting 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

20

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 any applications, including e-Commerce and web-based systems

21

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

22

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 results

23

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

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 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 (a.k.a. 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– Need to find common time 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 alignment

as the other 3 do. Negotiate?

27

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

28

You may use the Eclipse Standard

29

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– don’t do it!

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

30

Continuous Integration

Find problems earlyCan see if a change breaks the system more quickly -- while you remember the detailsAdd to the build on GitHub 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

Why Source Control?

Source control is the bedrock of software development – “Without some sort of version control system in

place, you can't reasonably call yourself a software engineer” Jeff Atwood

Why Git?

Need a place to store code when team size > 1There are many Revision Control Systems– Could be proprietary: IBM and MS have their own– Could have used CVS, Subversion, Mercurial

We use Git because – It is very popular with more than 11.2 millions repos– offers free private repos for students on GitHub

Basic Git

• Commands you’ll need to issue at the command line while in your local repository – init, clone, status, add (track, stage, or

resolve), commit, push, merge, pull (fetch & merge)

– .gitignore file lists what should be not pushed

/bin .classpath

Git has a Shared Repository Model

Prevalent with small teams and organizations collaborating on private projectsEveryone is granted push access to a single shared repository– We are pulling from and pushing to GitHub

Git Startup

One person create a private repo on GitHub – Initialize this repository with a README– Add .gitignore Java

Select SettingsSelect Collaborators and enter your passwordEnter user names of all team members– You will need to get all GitHub account names– Also include your product managers’

• Rick’s: rhm12399

Everyone Clone it

At GitHub, copy and paste the HTTPS clone URL– See URL beginning with https://github …

Issue this command while in the directory where you want to store the local repo

git clone https://github.com/rhm12399/fall14.git

If using Eclipse

Open Eclipse and selectFile > New > Java Project

Unclick Use default location, browse, click finish

Edit README.md

In Eclipse, add your name to the file README.mdFrom the command line where README is, enter

git status Untracked files: (use "git add <file>..." to include in …

git add . // “.” Means current folder Changes to be committed: new file: .classpath

new file: .project modified: README.md

git commit -m "Added name to README.md"

Push

You now have your local repo ready to push up to the shared repo on GitHub– You will be asked for your username / password once

git push origin master Username for 'https://github.com': rhm12399 Password for 'https://rhm12399@github.com': Counting objects: 11, done. Delta compression using up to 2 threads. Compressing objects: 100% (6/6), done. Writing objects: 100% (8/8), 955 bytes | …

Push

You now have your local repo ready to push up to the shared repo on GitHub

git push origin master On branch master Your branch is ahead of 'origin/master' by 1 … (use "git push" to publish your local commits)

nothing to commit, working directory clean

Git Workflow

Use the Centralized Workflow Model– git pull: update your local from remote in case

your teammates made changes– Make changes to code and perhaps add new files with

git add– git commit: commit all changes to your local repo– git push: push all changes to the remote repo

Try to be the only one to edit assigned filesNeed to add new files to be tracked: git add .