5 ms·

This paper doesn't just describe the waterfall, it explains why it doesn't work and proposes a more iterative approach, albeit with only two iterations.

Jtsummers 11y ago
If by two iterations you mean the paper suggests only going through the various components processes at most twice, that's not accurate. The method proposed involves feedback loops (Analysis->Design->Analysis->...) that could repeat multiple times. And the single steps back are the ideal. That is, you don't want to have to go back to Analysis from Testing, but you probably will have to for some projects from time to time.
- rossk14 11y ago
  I got the impression that the paper was suggesting an early, disposable prototype during the preliminary program design phase, similar to what Fred Brooks suggested back in the day. (http://c2.com/cgi/wiki?PlanToThrowOneAway http://c2.com/cgi/wiki?PlanToThrowOneAway) Meaning that the PPD phase was in effect an initial iteration through the development process. The outputs from that were used to generate the program design documents in the primary development process.
  - Jtsummers 11y ago
    I almost made a comment about that part. But that's the only part that's restricted (and then not strictly) to two "iterations". But I don't think that was what OP was referring to. > This paper doesn't just describe the waterfall, it explains why it doesn't work and proposes a more iterative approach, albeit with only two iterations. The iterative steps involved are not the throw one away bit, but the feedback loops in between the different stages of development. And the paper does not restrict its model to two iterations. The throw one away portion are the prototyping phase, which is the same development process in miniature. Like how, here, we might prototype our radio software without the hardware at all just to make sure we understand the protocol and other aspects correctly so when we do the full development on the radio (often with reused code from the prototype, though) it's better informed. [0] [0] Though, true to form, the last prototype became a delivered product instead of the basis for the final product. Oops. The dilemma of making a too good prototype, but not engineered well enough to actually be a final product. Maintenance has been a beast.
nickpsecurity 11y ago
That blew my mind, too. He preempts Spiral/Agile, re-did diagrams for complexity of real-world development, discoveries of maintenance phase as hardest, legal battles over blame, buy-in by stakeholders, mock-ups to catch requirements/design issues early, noting that's necessary in first place, and so on. Reading it makes me wonder what the (censored) people were reading when they described waterfall as a static, unrealistic process? In reality, it's so forward-thinking and accurate I might have to rewrite some of my own essays that were tainted by slanderous depictions of his Waterfall model.

Jtsummers 11y ago

If by two iterations you mean the paper suggests only going through the various components processes at most twice, that's not accurate. The method proposed involves feedback loops (Analysis->Design->Analysis->...) that could repeat multiple times. And the single steps back are the ideal. That is, you don't want to have to go back to Analysis from Testing, but you probably will have to for some projects from time to time.

rossk14 11y ago
I got the impression that the paper was suggesting an early, disposable prototype during the preliminary program design phase, similar to what Fred Brooks suggested back in the day. (http://c2.com/cgi/wiki?PlanToThrowOneAway http://c2.com/cgi/wiki?PlanToThrowOneAway) Meaning that the PPD phase was in effect an initial iteration through the development process. The outputs from that were used to generate the program design documents in the primary development process.
- Jtsummers 11y ago
  I almost made a comment about that part. But that's the only part that's restricted (and then not strictly) to two "iterations". But I don't think that was what OP was referring to. > This paper doesn't just describe the waterfall, it explains why it doesn't work and proposes a more iterative approach, albeit with only two iterations. The iterative steps involved are not the throw one away bit, but the feedback loops in between the different stages of development. And the paper does not restrict its model to two iterations. The throw one away portion are the prototyping phase, which is the same development process in miniature. Like how, here, we might prototype our radio software without the hardware at all just to make sure we understand the protocol and other aspects correctly so when we do the full development on the radio (often with reused code from the prototype, though) it's better informed. [0] [0] Though, true to form, the last prototype became a delivered product instead of the basis for the final product. Oops. The dilemma of making a too good prototype, but not engineered well enough to actually be a final product. Maintenance has been a beast.

nickpsecurity 11y ago

That blew my mind, too. He preempts Spiral/Agile, re-did diagrams for complexity of real-world development, discoveries of maintenance phase as hardest, legal battles over blame, buy-in by stakeholders, mock-ups to catch requirements/design issues early, noting that's necessary in first place, and so on. Reading it makes me wonder what the (censored) people were reading when they described waterfall as a static, unrealistic process? In reality, it's so forward-thinking and accurate I might have to rewrite some of my own essays that were tainted by slanderous depictions of his Waterfall model.