瀑布和螺旋式开发哪个更好？
当面试时被问及这样的问题时，面试官显然不是要一个简单的答案，中肯地指出每种方法优缺点比你的最终意见更重要。下面的答案可能是合适的。
项目SDLC方法的选择很大程度上取决于：
（1）项目的类型，
（2）项目内的环境或组织文化。
这样说来，螺旋法在今天的绝大多数项目中是优越的，尤其是那些包括面向顾客的产品的开发。
当螺旋方法首次被运用时，它计划用于非常大且复杂的问题。它结合了瀑布开发的特性（需求启发、分析、设计、代码、测试），但以迭代的方式完成。所以首先，应该注意的是，这两个并不完全是互斥的。
虽然螺旋方法的每一次迭代周期可能是6个月至一年甚至更长时间，但随着近年敏捷开发的兴起，螺旋方法的迭代周期已经压缩到更小的时间范围。有时短于2周，更多的是一两个月。
任何迭代方法都可以提供超过其瀑布版本的诸多好处：
- 软件的可用性达成更快，从应用程序用户那里就能获得更直接的反馈
- 通过短迭代开发并立即发布到生产的软件功能，可以获得更直接，更大的ROI
- 由于较小的工作单元通常需要较小的团队规模，因此项目开销较少
- 避免大规模超时
- 避免大笔预算超支
当然，理论上看起来很不错，还需要测试功能是否能正常运行。这就是大多数分析家讨论结束的地方。
然而，螺旋法也有一些缺点。
对于遵循Spiral方法的敏捷团队来说，很容易养成进行草率的预先分析的习惯，因为在将来的迭代中可以修复需求或特性的缺失。虽然Spiral方法确实减轻了丢失重要事项的一些影响，但是这种惰性也可以消除Spiral方法的一个重要优点：从早期的版本的中捕获额外的ROI。
最后，也是最重要的是，任何迭代方法都意味着在知道整个设计范围之前，产品/应用程序的各个部分已经在设计编码。这可能会导致大量的UI和代码重构;重构是用于描述现有系统的部分的重新设计和重新编码以便适应新特征和功能的术语。至少，这意味着原本可能避免的重大返工。
然而，一些早期的系统设计和架构决策有时会限制在未来可实现的目标。因此，在最坏的情况下，这可能意味着最终重新设计和重写整个产品或系统。这并不意味着不应使用螺旋方法。在大多数情况下，它的优点远大于它的缺点。但项目团队成员应该意识到风险，以便他们可以尽早建立流程和习惯，从而有助于降低这些风险。