瀑布模型：
瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
简单的说就是先定好需求和相关文档，然后构建框架，然后写代码，然后测试，最后发布个产品
一旦文档需求确定，开发人员就按文档开发，直到产品开发完后，才会拿出来给客户。不过这种方式基本不适应现今快速发展的市场现状了。
迭代模型：
迭代的方式就有所不同，假如这个产品要求6个月交货，我在第一个月就会拿出一个产品来，当然，这个产品会很不完善，会有很多功能还没有添加进去，bug很多，还不稳定，但客户看了以后，会提出更详细的修改意见，这样，你就知道自己距离客户的需求有多远，我回家以后，再花一个月，在上个月所作的需求分析、框架设计、代码、测试等等的基础上，进一步改进，又拿出一个更完善的产品来，给客户看，让他们提意见。
就这样，我的产品在功能上、质量上都能够逐渐逼近客户的要求，不会出现我花了大量心血后，直到最后发布之时才发现根本不是客户要的东西的情况。
两种方法的比较：
瀑布模型：假如我们对用户的需求判断的不是很准确时——这是很常见的问题，一点也不少见——你开发了几个月甚至是几年，当你把产品拿给客户看时，可能与客户原先想要的相差很远。
迭代模型：相较瀑布较好，但也有自己的缺陷，那就是周期长、成本很高。适合大项目、高风险项目，比如是航天飞机的控制系统时，迭代的成本比项目失败的风险成本低得多，用这种方式明显有优势。