快速原型模型
运用场景：
很多时候，客户定义了软件的一些基本任务，但是没有详细定义功能和特性需求。另一种情况下，开发人员可能对算法的效率，操作系统的适用性和人机交互的形式等情况并没有把握。在这些情况和类似情况下，采用原型开发范型是最好的解决办法。
快速原型模型的主要思想是：
首先快速建立一个能够反映用户主要需求的原型系统，让用户在计算机上试用它，通过实践让用户了解未来目标系统的概貌，以便判断哪些功能是符合需要的，哪些方面需要改进。用户会提出许多改进意见，开发人员按照用户的意见快速地修改原型系统，然后再次请用户试用……，这样反复改进，最终建立完全符合用户需求的新系统。
一旦用户认为这个原型系统确实能做他们所需要的工作，开发人员便可据此书写规格说明文档，根据这份文档开发出的软件可以满足用户的真实需求。
在建立原型时应采取如下方法。
1）为了减少原型系统的开销，可以采用一些特殊的有别于通常软件开发时使用的技术和工具，可以采用功能很强的甚高级语言实现原型系统，如Unix支持的SHELL语言就是一种功能很强的甚高级语言，它执行速度比较慢，但它所需成本比用普通程序设计语言开发时低得多。在建立原型模型时这个优点是非常重要的。原型系统的另外一个长处是可以在各种不同类型的计算机上运行，暂不考虑速度、空间等性能效率方面的要求；不考虑错误恢复和处理。
2）如何产生最终的软件产品？可以把原型系统作为基础，考虑到原型系统的界面是与用户通信的“窗口”部分，通过这个“窗口”用户最容易获取信息和发表自己的意见。原型系统的界面要设计得简单易学，且最好与最终软件系统的界面相容。通过补充与修改获得最终的软件系统。但在实际中由于开发原型系统使用的语言效率低等原因，除了少数简单的事务系统外，大多数原型模型都废弃不用，仅把建立原型模型的过程当作帮助定义软件需求的一种手段。
主要优点：
- 软件产品的开发基本上是按线性顺序进行的。
- 原型系统已经通过与用户交互而得到验证，据此产生的规格说明文档正确地描述了用户需求，因此，在开发过程的后续阶段不会因为发现了规格说明文档的错误而进行较大的返工。
- 开发人员通过建立原型系统已经学到了许多东西（至少知道了“系统不应该做什么，以及怎样不去做不该做的事情”），因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。
- 软件产品一旦交付给用户使用之后，维护便开始了。根据用户使用过程中的反馈，可能需要返回到收集需求阶段.
原型的用途是获知用户的真正需求，一旦需求确定了，原型将被抛弃。因此，原型系统的内部结构并不重要，重要的是，必须迅速地构建原型然后根据用户意见迅速地修改原型
从图 2.3 可以看出，快速原型模型是不带反馈环的
2．可以在各种不同类型的计算机上运行，暂不考虑速度、空间等性能效率方面的要求；不考虑错误恢复和处理。
3．是一种循环进化的过程，用户的参与和反馈，使得这种方法开发出来的系统能够更好地满足用户的需求。
存在问题：
1.利益相关者看到了软件的工作版本，却未察觉到整个软件是随意搭成的，也未察觉到为了尽快完成软件，开发者没有考虑整体软件质量和长期的可维护性。当开发者告诉客户整个系统需要重建以提高软件质量的时候，利益相关者会不愿意，并且要求对软件稍加修改使其变成可运行的产品。在绝大多数的情况下，软件开发管理层会做出妥协。
2.作为一名软件工程师，为了使一个原型快速运行起来，往往在实现过程中采用折衷的手段。他们经常会使用不合适的操作系统或程序设计语言，仅仅因为当时可用或他们对此较为熟悉。他们也经常会采用一种低效的算法。仅为了证明系统的能力。时间长了，软件开发人员可能会适应这些选择，而忽略了这些选择其实并不合适的理由，结果使并不完美的选择成了系统的组成部分。