什么是原型模型
原型模型一般在需求提出初期，用户迫切需要体验产品，开发人员根据核心功能需求快速实现的一款可以用来演示的产品，形成demo，可快速挖掘是否是用户真正想要的产品。但这种模型在整个软件项目周期内只可能存在于这期间，当用户了解了demo后决定是抛弃还是继续采用，抛弃相当于需求双方没有达成一致，可以再次采用原型模型输出给用户确认，若选择不抛弃继续采用，原型模型就会被抛弃，选择其他模型继续开发。
主要针对事先不能完整定义的软件开发，是在快速开发一个原型的基础上，根据用户在使用原型的过程中提出的意见和建议对原型进行改进，获得原型的新版本。重复这一过程，最终可得到令用户满意的软件产品。快速原型模型
快速原型（Rapid Prototype）模型在功能上等价于产品的一个子集。注意，这里说的是功能上。瀑布模型的缺点就在于不够直观，快速原型法就解决了这个问题。一般来说，根据客户的需要在很短的时间内解决用户最迫切需要，完成一个可以演示的产品。这个产品只是实现部分的功能（最重要的）。它最重要的目的是为了确定用户的真正需求。在我的经验中，这种方法非常的有效，原先对计算机没有丝毫概念的用户在你的原型面前往往口若悬河，有些观点让你都觉得非常的吃惊。在得到用户的需求之后，原型将被抛弃。因为原型开发的速度很快，设计方面是几乎没有考虑的，如果保留原型的话，在随后的开发中会为此付出极大的代价。至于保留原型方面，也是有一种叫做增量模型是这么做的，但这种模型并不为大家所接受，不在我们的讨论之内。 上述的模型中都有自己独特的思想，其实软件组织中很少说标准的采用那一种模型的。模型和实用还是有很大的区别的。 软件生命周期模型的发展实际上是体现了软件工程理论的发展。在最早的时候，软件的生命周期处于无序、混乱的情况。一些人为了能够控制软件的开发过程，就把软件开发严格的区分为多个不同的阶段，并在阶段间加上严格的审查。这就是瀑布模型产生的起因。瀑布模型体现了人们对软件过程的一个希望：严格控制、确保质量。可惜的是，现实往往是残酷的。瀑布模型根本达不到这个过高的要求，因为软件的过程往往难于预测。反而导致了其它的负面影响，例如大量的文档、繁琐的审批。因此人们就开始尝试着用其它的方法来改进或替代瀑布方法。例如把过程细分来增加过程的可预测性。
原型模型主要阶段
优缺点
优点：
- 快速了解用户真正想要实现的样子，整个项目可行性强。
- 克服瀑布模型的缺点，更好地满足用户的需求并减少由于软件需求不明确带来的项目开发风险。适合预先不能确切定义需求的软件系统的开发。
- 没有考虑软件的整体质量和长期的扩展和维护；
- 快速输出demo的方法不一定会真正采用；
- 只在用户需求目标模糊，急需看到效果的情况下使用。
- 不适合大型系统的开发（适合开发小型的、灵活性高的系统）。前提要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新。