The two processes I will be looking at and comparing from my software development experience are the Waterfall and Iterative software design models with respect to Software Design Architecture. Both are widely used in practice and it’s unlikely both are explicitly adhered to, with people most likely opting for a combination of the two. The information below is mainly my opinion and relates to my experience working with both models in jobs.
As seen in the images above, the style of development the Waterfall model (left) encourages is that each stage is defined before starting it and completed before moving onto the next stage. The Iterative model (right) however encourages a more agile style of development. Software is written in small increments and tested with users or by the developers from a user point of view before accessing the quality of the software and considering requirement refinements for another development iteration.
The planning of a Software Project developed using the waterfall model is far more detailed than that of one with the iterative model. This enables the development team to have a structured timescale with all the requirements listed and scheduled, making funding the project much more straightforward (although statistically timing and funding targets are unlikely to be achieved).
The planning of an iterative development project is simply a set of functional and non functional requirements before development begins. Planning for budget and timescale isn’t as easy as the waterfall model simply because the requirements aren’t necessarily finalised at this stage. A rough outline can be easily drawn up with a timescale. It is however more difficult to keep to than a project using the Waterfall model due to the uncertainty regarding the requirements.
The requirements of a Waterfall Model project are detailed and set and the start of the project and the following processes are built upon that. Little or no change is made to them throughout the lifecycle of the project. This results in problems if a client requires a change of requirements. Large amounts of work may be discarded if the new requirements deviate too much from the old.
This iterative development cycle is highly susceptible to changes in requirements. The constant refinement of the requirements after every iteration allow for the project to easily pivot to fit another set of requirements without too much work being lost. This allows us to tailor the software to the best it possibly can be through evaluation, over simply implementing the original vision without taking the time to go back and reconsider user testing results or how it could be made better.
Both development cycles allow for test driven development. The benefits of a Waterfall model, knowing all the requirements from the onset allows for the test suite to be planned, developing a framework which covers all the functionality of the software. The Iterative only allows for behavioural development of a more agile nature nature. While it is possible to later draw up a test suite with 100% coverage, this is often time consuming and defeats the purpose of why one would develop iteratively over waterfall.
User testing a product in a waterfall model project is often a hit and miss experience. By this stage, if the feedback is negative, it’s not possible to rectify any major problems due to funding/time restraints. The iterative model however lends itself far better to user testing. If the product is user tested after every iteration, it is possible to act on, and tailor the software to the user’s feedback.
Maintaining a software project developed on either model is most likely going to be an agile experience. Small requirement changes such as new features or adapting it to suit a new OS are simple enough to be developed in iterations, in short development cycles.
In closing, larger corporate structures are going to be happier with the Waterfall models, ensuring a direct map of timescales and funding. Startups however tend to adopt a more agile, iterative model with their software. Constantly improving and refining what they have created. Both have their perks as we have seen above, but I believe the agile, iterative model to be the best. If done correctly, it creates a piece of software which is highly suited to the user’s requirements over what we assume the user might want in the waterfall model.