Is Pure Waterfall a Fallacy?
Just was pondering on this question, Is Pure Waterfall a Fallacy? In reality its just not possible to have Pure waterfall for Software or any industries.
Waterfall asks us to go sequentially from one phase to another phase without allowing us to go to previous phase. So typically waterfall has Requirements, design, coding, testing and operations.If thats the case then why do we have testing phase? Testing will uncover defects on coding and that means we would be revisiting coding phase again!! A violation of waterfall principle.
We all call what we do a waterfall methodology, but in reality doing a modified waterfall. Also as per waterfall, once testing uncovers defects, the product becomes scrap as there is no more revisiting previous phase ( as per waterfall)
The tasks may work individually. Waterfall recognizes the parts may not integrate together. Then there is allocation of time for getting the pieces to fit.
My words are not from some official place. It is only what I have encountered.
I've studied software engineering processes during my Comp Sci major. I can tell you, there is no official "waterfall" process for say. Just like there is no official Agile process. It's just a general category that encompases many methodology.
Just as Agile is a category that is more of a bottom up iterative process, waterfall describes a more top down plan first methodology. Another large category is Spiral/Evolutionary (starts off top down, then slowly transitions to iterative).
When I worked in a RUP (Rational Unified Process), we had a issue triage board that consisted of all the leads of the different groups. When a bug was raised, we evaluated the criticality of the bug, and determined if we could release with the bug, work through it and fix it, or do we have to revisit the drawing board and start over at design and inception.
Starting over does have it's advantages. It allows you to revisit the design and resource allocation while Agile teams tend to have fixed resource allocation and has less focus on design. This avoids jumping down the rabbit hole problem. Say for example, you hit a flaw that questions the assumptions made going into a project, such as staffing an engineer that's too inexperienced for that particular project. In Agile, replacing an engineer is very hard to do because it's very bottom heavy process. Where a top have process, you can identify the skill gap, look at the big picture, and reassign resources.
Tags for this Thread