A comparison of two common software development methodologies, Waterfall and Iterative, with a focus on Web Application development projects.
It describes their respective processes, examines their differences, discusses their advantages and disadvantages, and finally, identifies which situations each is most appropriate for, and their criteria for success.
The other day at work some colleagues asked me about Iterative development, so I thought I’d write some notes on the subject based on my experiences with it (i.e. web application development), comparing it to the more traditional Waterfall methodology.
|
Waterfall |
Iterative |
| Process |
- Gather and analyse requirements
- Design and document solution
- Implement system
- Test
- Deploy
|
- Identify desired elementary features and prioritise in order of business value, ensuring features do not contain multiple smaller features that could in fact exist, and be of business value, individually
- Tackle each elementary feature in order of priority in an iteration which includes all the steps of the waterfall process
- Iterations ought to last between 1 and 4 weeks depending on the work involved to deliver each elementary feature
- After each iteration re-evaluate priorities
|
| Differences |
- Predictive
- More written communication
- Test at the end of development
- More junior developers
- Uses planning as control mechanism
- Traditionally fixed cost, time and specification
|
- Adaptive
- More face to face communication
- Test after each iteration
- Fewer senior developers
- Uses feedback as control mechanism
- Clients are charged for each iteration at a time
|
| Advantages |
- Accurate estimates of time and budget can be generated based on a full set of requirements.
- The developer has knowledge of all requirements and can design a solution to fit them all before coding begins.
|
- Fuctionality that adds the most business value (considering business and their customer needs) is delivered first, bringing forward the time to market, and through continuous feedback and planning, value is maximised throughout the project lifecycle.
- Actual working software facilitates identification of problems earlier, minimising risk and ensuring a better product aligned with business and customer needs.
- It is easier to manage changing priorities and requirements during the development.
|
| Disadvantages |
- Considerable input is required from the client at the start of the project, as all requirements must be gathered and the system designed up front, when the client may not know exactly what they want or the best way of implementing a feature.
- Testing only starts after development is complete which means that the client doesn’t get to see any functionality until its already been built, and may not be what they actually wanted. Therefore it is more likely to include features that must be changed or not actually needed.
- The software is generally not released until the project is completed therefore it cannot generate any value for the client until this stage.
- Individuals can influence design decisions based on personal opinions which may not be optimal.
- Time can be wasted at the start creating little read/understood documentation.
- The developer must have an appreciation of the whole application up front.
|
- There is no long term planning capability and consequently it is impossible to estimate accurately costs and times.
- Subsequent iterations will likely require time for refactoring existing code that could otherwise have been avoided if the new iterations requirements were understood when writing the code previously.
- Not all desired features may be implemented within the client’s required time or budget.
|
| Uses |
- For high risk and life/mission critical systems.
- Where all requirements are known up front and are unlikely to change during the development.
- For clients whose main priority is time or budget.
- For clients who do not have the time to devote to testing and providing timely feedback, or being on site to communicate with the developers.
|
- For low criticality systems.
- For clients who do not know how to define what they want.
- On projects whose full requirements are unknown or may change during the development.
- For clients whose main priority is a superior usable product.
|
| Success criteria |
- Requirements do not change during the development.
- All requirements are identified at the start.
- People responsible for requirements gathering are fully capable of doing this.
- Formal change control procedures in place and adhered to.
|
- Communication of requirements from client to developer
- Trust in developer’s abiilty to make decisions
- Timely testing and feedback from the client
|
Both these development methodologies are in fact umbrella terms that actually encompass several specific methodologies of slightly different variations. A subset of the group of Iterative methodologies commonly used in Web Application development is called Agile.
In essence, the Agile approach claims it will provide the most bang for the buck, but won’t say exactly when that bang will be or how big a buck will ultimately be required.
Wikipedia
So, as you can see, each methodology has its own merits and is most applicable to different clients, projects, teams and circumstances.
As I mentioned above, these are just my experiences – if you think I’ve missed a critcal point, leave a comment below.
~o0o~
Loading ...
Leave a comment