Incremental Development
Incremental Development
Note that not all iterations need be complete, fully functional software. Nor should they
necessarily focus on the same areas of functionality. It is better to deliver separate 'increments' of
functionality and assemble the whole project only at the conclusion of the production phase. This
way you can take partial steps towards your completed goal. Each unit can be individually
developed, tested and then bolted together to form the overall product or system.
The diagram above indicates progress through the development life-cycle in an iterative /
incremental development. Early on the iterations focus on 'design tasks' and the emphasis is on
making design decisions and prototypes. As the project progresses tasks shift to development
where the bulk of the coding is done. Finally, the emphasis is on testing or evaluation to ensure
that what has been developed meets requirements and is solid, stable and bug free (ha!).
The New Software Development Methodologies
On the back of 'rapid' development methodologies have come a swag of 'process-lite' software
development models that focus on harnessing the creativity of software developers. They include
things like SCRUM, Extreme Programming and AUP.
The methods involved range from the harmless or practical to the outright bizarre.
The models have their advocates in the industry and some notable successes but they also have
their crashing failures and the overall performance of these techniques can be best described as
mediocre. A friend of mine summed it up best when he said, "They work really well if you have a
good team, but then anything works really well if you have a good team."
This primer will focus on testing in traditional methodologies although some of the fundamental
concepts mirror those from newer software development methodologies.
I have to agree with Fred Books in his seminal paper, "No Silver Bullet", when he said "There is no
single development, in either technology or in management technique, that by itself promises even one order-
of-magnitude improvement in productivity, in reliability, in simplicity."
He was reacting to cries for a change in software development practices which would bring about
order of magnitude improvements in the productivity of software development (which would match
the order of magnitude increases being made in computer hardware).
Brooks argued that while innovation was useful, no single process would revolutionise software
development. What was needed instead was a disciplined, ordered approach that delivered step-wise
improvements to the process.
That was written in 1986 and we're still looking for the holy grail.
6
Figure 4: Incremental development