For the senior project class I am currently taking we are using the waterfall design pattern. Waterfall is a linear process where each step is only taken once the previous step is fully completed. This means that the research is done first, the design is only started once the research is fully complete, and so on. This model is the simplest of software design patterns as well as the closest to a ‘traditional’ model.
In my previous projects the only true design pattern I had used was agile, when I took Software Engineering 1. Agile is focused on continuous design and development of software. This design pattern is comprised of self-contained cycles of development called ‘sprints’. In a sprint the planning, design, development, and testing is done for a small subset of the final program’s features. All of the other projects or assignments I have worked on did not require any specific design pattern or, in most cases, collaboration with teammates. Because of this I usually chose to not use any design pattern while developing programs.
Waterfall offers several benefits over the systems I have previously used. The design model requires good planning and research ahead of the beginning of development whereas with agile one could make a fair amount of progress into a project without noticing a design problem. This pattern also is more straightforward than others as it follows an intuitive progression of planning, development, and deployment.
The problems with waterfall design are unfortunately just as numerous as its advantages. With waterfall the design cannot accommodate any change in the requirements of the project or any new information about the technologies of project components. Importantly, other design patterns such as agile are better suited to modern software companies who create programs and applications for the general public. These companies are constantly adding features or modifying existing ones, a process which is not covered under the waterfall method.
This leads me to the conclusion that waterfall is better for small systems where the time cost of planning sprints and assigning roles outweighs that of planning the entire project up front, and critical systems which need to be planned clearly and produce well-structured software.
