Xtreme Programming. Software Life Cycle The activities that take place between the time software program is first conceived and the time it is finally.

Xtreme Programming

Software Life Cycle

The activities that take place between the time software program is first conceived and the time it is finally retired.

5 Phases of software engineering

Analysis Design Implementation Testing Deployment

Waterfall model

When the process was first developed in the early 1970’s it was postulated that one phase would run to completion, its output would spill over to the next phase, and the next phase would begin.

This model was called the Waterfall model

Problems with the Waterfall

Figure out what Figure out how Then do it Verify was done right Hand product to

customer

Perfect requirement definition?

The Spiral Model

Proposed by Barry Boehm in 1988. Breaks the development process down into

multiple phases. Early phases focus on construction of

prototypes

Problems with the Spiral

By building in repeated trials and feedback, a development process that follows the spiral model has a greater chance of delivering a satisfactory system.

BUT there is a danger that if engineers believe that they don’t have to do a good job because they can always do another iteration, then there will be many iterations and the process will take a long time to complete

More problems!

Not enough time to test due to pressure to get new software or new versions out fast

Breakdown in communication between programmers and management

Blamed by managers if things go wrong Business problem changes half way through

project

What is needed

Continuous feedback Incremental planning Test driven development Collective ownership Simplicity Support for difficult decisions

New Philosophy

Set of Practices

Realistic Planning– Customers are to make business decisions,

programmers are to make technical decisions– Update the plan when it conflicts with reality

How does this help?

Set of Practices

Small Releases– Release a useful system quickly– Then release updates on a very short cycle.

How does it help?– Reduces risk of schedule slip and project

cancellation– a small release that actually works establishes

credibility– Gets the customer involved

Set of Practices

Metaphor– All programmers should have a simple shared story that

explains the system under development– “This program works like a hive of bees, going out for pollen

and bringing it back to the hive.”: description of an agent based information system

How does this help?– Use of a common system of names ensures that everyone

understands how the system works and where to find the functionality they are looking for

Set of Practices

Simplicity– Design everything to be as simple as possible

instead of preparing for future complexity

How does this help?– Avoids “featuritis” and maintains focus on the real

problems

Set of Practices

Test Driven Development– The system is continuously tested in short cycles

of adding a test and making it work– When the code is released to the repository, all

the tests MUST run 100% of the time

Set of Practices

How does this help?– Programmers get immediate feedback– Leads to almost 100% test coverage– If the defect rate of an implemented system is too

high, the system might be discarded or replaced

Set of Practices

Customer Tests– The customer defines one or more automated

acceptance tests to show that the feature is working.

– Once the test runs, the team keeps it running correctly thereafter.

How does this help?– The system only improves, always notching

forward

Set of Practices

Refactoring– Programmers are to restructure the system

continuously to improve the code and eliminate duplication

– And increase the cohesion of the code while lowering the coupling (hallmarks of well designed code)

How does this help?– Good, simple design helps maintain development

speed

Set of Practices

Pair programming– Two heads are better than one– Put programmers together in pairs, and require

each pair write code on a single computer

Set of Practices

How does it help?– Programmers do not feel isolated or unsupported– Provides better code and tests– Serves to communicate knowledge throughout

the team– As pairs switch, everyone gets the benefit of

everyone’s specialised knowledge– Programmers learn, their skills improve, they

become more valuable to the team and to the company.

Set of Practices

Collective Code Ownership– All programmers have permission to change all

code as it becomes necessary How does this help?

– All code gets the benefit of many people’s attention, which increases code quality and reduces defects

– Avoids an individual putting a feature in the wrong place, code duplication and low or bad cohesion

Set of Practices

Continuous integration– Whenever a task is completed, build the entire

system and test it.– This could mean multiple builds per day!

How does this help?– Ever made several changes to code in different

places, then built the system and …it does not work? And not known why?

Set of Practices

Continuous Integration How does this help?

– The team gets practiced at integration by doing it frequently, rather than delegating it to people not familiar with the whole system

– Detects bugs that are not detected by testing– Avoids time lost due to code freezes

Set of Practices

40 hour week– Don’t cover up unrealistic schedules with bursts of

heroic effort.

How does this help?– Enables work at a sustainable pace

Set of Practices

On-site customer– An actual customer of the system is to be

accessible to team members at all times.

How does it help?– Reduces chance of the business being

misunderstood– The specification can be continuously refined to

meet expectations

Set of Practices

Coding standards– Programmers are to follow standards that

emphasize self-documenting code– All the code in the system looks as if it was written

by a single – very competent – individual.– The specifics of the standard are not important

How does it help?– Supports collective ownership

Synergy

Beck claims that the value of the Extreme Programming approach lies in the synergy of these practices – the sum is bigger than the parts.

Refactoring is strongly supported by comprehensive testing to be sure that as the design evolves, nothing is broken. Thus customer tests and programmer tests are a critical enabling factor. The XP practices support each other.

XP Practices