又如: Winston 指出, 要让产品成功, ***把这个模型走两遍，先有一个模拟版本 (simulation of final product), 在此基础上收集反馈, 改进各个步骤, 并交付一个最终的版本:
Winston 还指出, 用户的及早介入, 讨论，复审是很重要的。他建议–
Customer involvement should be formal, in-depth, and continuing.
他也提到在这个模型下文档的重要性: 下面的图中显示了8 种文档:
有讽刺意义的是, 似乎其他人并没有仔细读这个论文, 一些人看了图, 觉得很爽, 就拿来用了，而且希望waterfall 一次就把产品做好，同时产生出好些有用的文档。 一时间Waterfall 传播开来了。对于它的缺点, 一些人不正确地指责 Winston。
可以看看网友做的漫画, 看看 Waterfall 的传播和误解：
the rise and fall of waterfall: Royce Winston
***.com/watch?v=X1c2--sP3o0
尽管狭隘定义的瀑布模型有这样那样的问题, 我个人认为这个瀑布模型还是反映了人类解决问题的一个常用的模型。它在软件工程中的局限性在于–
· 各步骤之间是分离的，（但是软件的生产过程中的各个步骤不能这样严格分离出来。）
· 回溯修改很困难甚至不可能, (但是软件生产的过程需要时时回溯)