09-03-2012, 02:31 PM
extreme programming
[attachment=18148]
A methodology is a formalized process or set of practices for creating software
An early methodology was the waterfall model, so named because each stage flowed into the next, with no backing up to a previous stage
The stages were: Requirements Design Implementation Verification Maintenance
The waterfall model has never been regarded as a “good” model
Methodologies are subject to fads, and are frequently imposed on programmers by management
Some methodologies are bad—even ridiculously bad
This doesn’t mean all methodologies are bad
However, a single methodology doesn’t work for all cases
Agile programming methodologies
There are (at least) two serious problems with the waterfall model:
It assumes that there will be no unforeseen difficulties in the software development
It assumes that the customers know (and can specify) what they want, in extreme detail
Agile programming methodologies (of which there are several) assume:
Customers can best discover what software meets their needs via frequent iterations
Hence, communication between customers and developers is vital
Requirements will need to be revised, probably multiple times, during software development
Extreme programming
In this course we will draw on a number of ideas from one particular agile methodology, Extreme Programming (XP)
The basic idea of extreme programming is to take to an extreme each of several known good practices
“The first time I was asked to lead a team, I asked them to do a little bit of the things I thought were sensible, like testing and reviews. The second time there was a lot more on the line. I thought, "Damn the torpedoes, at least this will make a good article," [and] asked the team to crank up all the knobs to 10 on the things I thought were essential and leave out everything else.” — Kent Beck
For example, it is well known that software should be tested frequently during development
Extreme programming advocates testing code literally every few minutes, after every minor change
Extreme programming works best for relatively small projects with a small number of good programmers
[attachment=18148]
A methodology is a formalized process or set of practices for creating software
An early methodology was the waterfall model, so named because each stage flowed into the next, with no backing up to a previous stage
The stages were: Requirements Design Implementation Verification Maintenance
The waterfall model has never been regarded as a “good” model
Methodologies are subject to fads, and are frequently imposed on programmers by management
Some methodologies are bad—even ridiculously bad
This doesn’t mean all methodologies are bad
However, a single methodology doesn’t work for all cases
Agile programming methodologies
There are (at least) two serious problems with the waterfall model:
It assumes that there will be no unforeseen difficulties in the software development
It assumes that the customers know (and can specify) what they want, in extreme detail
Agile programming methodologies (of which there are several) assume:
Customers can best discover what software meets their needs via frequent iterations
Hence, communication between customers and developers is vital
Requirements will need to be revised, probably multiple times, during software development
Extreme programming
In this course we will draw on a number of ideas from one particular agile methodology, Extreme Programming (XP)
The basic idea of extreme programming is to take to an extreme each of several known good practices
“The first time I was asked to lead a team, I asked them to do a little bit of the things I thought were sensible, like testing and reviews. The second time there was a lot more on the line. I thought, "Damn the torpedoes, at least this will make a good article," [and] asked the team to crank up all the knobs to 10 on the things I thought were essential and leave out everything else.” — Kent Beck
For example, it is well known that software should be tested frequently during development
Extreme programming advocates testing code literally every few minutes, after every minor change
Extreme programming works best for relatively small projects with a small number of good programmers
