I’m just going to say this right of the bat. I really don’t like the waterfall method. The whole idea of the waterfall method is dividing the software development into 6 main concepts and areas.
- Finding out the requirements for the development of your software.
- The Analysis: you determine your project using models, schemas, and a business model.
- Design: You design the software architecture.
- Coding: You code.
- Testing: debugging, and problem solving.
- Operations: Installation, migration, support, and maintenance of the work (IMSM? Doesn’t sound too catchy).
Here’s a pretty picture to understand it better:
The whole idea of this method is to keep track of what you want, how you want it, and how you’re going to make it. If focuses a lot in the planning, and documentation of the software that is being developed. This is why I don’t like it. It’s important to keep track of what is being done, how it’s being done, and to make sure that everyone involved in it knows what is happening. However, sometimes projects using this method focus a lot on the documentation, and administrative side of it. This means that there might not be enough attention in the actual software implementation, and the client’s satisfactory level.
