快速原型化模型的基本思想是：在需求分析的同时，以比较小的代价快速建立一个能够反映用户主要需求的原型系统。用户在原型系统上可以进行基本操作，并且提出改进意见，分析人员根据用户的意见完善原型，然后再由用户评价，提出建议，如此往复，直到开发的原型系统满足了用户的需求为止。基于快速原型化模型的开发过程基本上是线性的，从创建系统原型到系统运行，期间没有反馈环。这是由于开发人员是在原型的基础上进行系统分析和设计，而原型已经通过了用户和开发组的审查，在设计阶段由于有原型作设计参考，所以设计的结果正确率比较高。
快速原型的本质是快速开发出系统的原型，以便让用户确认什么是真正的需求，一旦用户确认了需求，原型通常将被抛弃。因此，快速原型的内部构造并不重要。
螺旋模型螺旋模型结合了前面介绍的所有模型的特点，它是由Boehm于1988年提出的。它的基本思想是通过建立原型、划分开发阶段来降低风险。
螺旋模型比较适用于产品研发或机构内部较大规模的复杂系统开发。这是因为螺旋模型是以风险驱动的，一旦在开发过程中风险过大就停止继续开发，因此，它不适合作为合同项目的开发。如果作为合同项目的开发模型，则要在签订合同之前将所有的风险考虑清楚，否则，不管哪一方中途停止开发可能都会导致经济赔偿或承担法律责任。
螺旋模型一般被划分为2―6个框架活动，沿着顺时针布局;如下图：
其中的活动分别是：
制定计划（左上象限）——明确软件目标，确定实施方案，设定约束条件。风险分析（右上象限）——针对确定的实施方案，评价可能的风险、制订控制风险的措施。实施工程（右下象限）——实施软件开发，对于不确定的需求通过构造原型最终确定下来。客户评价（左下象限）——评估开发工作、提出修正建议。沿螺旋线自内向外每旋转一圈便开发出更为完善的一个新的软件版本。首先，确定初步的目标，制定方案和限制条件，进入右上象限，进行风险分析，进入右下象限，开发原型，以帮助客户和开发人员理解需求，通过对原型进行评价，修正需求。根据用户提出的建议进入螺旋的第二层，又与用户交谈，再次执行计划和实施方案，然后再一次分析实施的风险，如果风险过大，可以就此终止，否则再次进入实施阶段，用户评价这一轮的实施结果，并提出修改建议。然后进入第三层螺旋……，如此下去，逐步延伸，最终用户获得完整的系统。
螺旋模型的主要优势在于它是风险驱动的，每个方案在实施前都要经过风险分析。如果风险过大，则项目应该停止，或改变方案。
瀑布模型瀑布模型是由W.Royce于1970年首先提出的。瀑布模型规定了软件生命周期的各项活动：问题定义（可行性研究阶段），需求分析，软件计划，软件设计，编码，测试，运行和维护。各项活动自顶向下、相互衔接如同瀑布一样。这里的修饰词“瀑布”非常贴切，明确了一个活动结束，进入到下一个活动后，很难再回到前一个活动中去，也就是工作不可逆转，正是这个特点为瀑布模型带来了致命的问题。
首先是确定问题域，并接受用户和项目小组的审查；在审查通过后，进行需求分析，编写需求分析规格说明书，需求规格说明书也要经过用户和项目小组的审查；一旦用户在需求规格说明书上签字后，就要编写详细的开发计划；当开发的进度和费用估算等评估通过后，就开始设计工作；设计说明书被审查通过后，开始编写程序代码并进行单元测试；最后将所有的模块集成在一起，进行集成测试和系统测试，之后由用户进行验收测试，验收测试通过后交付用户使用。
如下图：
瀑布模型最重要的特点：只有当一个阶段的任务完成、交付相应的文档、通过审查小组的审查合格后，才能开始下一个阶段的工作。如果审查没有通过则要进行修改，有时可能是由于前一阶段的问题，使得本阶段不能通过审查，这种情况下就要使用带反馈的瀑布模型；
如下图：
带反馈的瀑布模型在每个阶段都可以修改前一个阶段存在的问题，事实上，问题发现得越早越有利。当系统进入运行维护阶段后，仍然可能添加或更改需求，这实际上相当于进行二次开发，要对变化的需求进行分析、设计、编码和测试；除此之外，维护还包括纠正错误的需求、错误的设计和错误的编码，因此，从运行维护阶段可以向适当的阶段反馈。
瀑布模型广为流传，它配合结构化方法和严格的软件开发管理手段，在软件工程化开发中起了重要作用。但是，通过长期的实践活动，人们发现，这种模型应付需求变化的能力非常弱。在项目刚刚开始时，系统分析人员和用户对新系统的需求很难完全描述清楚。特别是用户日常的一些工作，在他们看来已经是习以为常的活动，常常被无意识地忽略，而系统分析人员通常不是用户业务领域的专家，不知道这些活动。直到开发人员按照需求规格说明书开发出系统后，用户发现不符合业务需求，但为时已晚。因为这时对系统做修改，不但造成开发成本提高、交付期延迟，最关键的是会大幅度地降低软件的质量。
许多用户在没有看到开发好的软件之前，对自己到底需要什么样的软件没有一个完整概念，当软件开发出来之后，会提出许多合理的、非常好的意见。可是重新设计、编码、测试的工作量通常开发商们都承受不起。遇到这种情况时，开发人员和业务人员常常因此造成不愉快，严重时还会给双方造成巨大的经济损失。为了避免这类问题，人们发明了快速原型化模型。
V模型软件工程强调的是对软件开发过程的控制和对软件产品的质量的保证，V模型将开发活动与测试活动紧密地联系在一起，在代码产生之前的每个阶段都要开展对应的测试设计。
V模型如图所示：
V模型是瀑布模型的一个变种，但它更强调在软件的开发过程中考虑软件的质量。在程序代码没有产生之前是无法通过运行程序进行软件测试的，因此在需求分析阶段要设计软件验收时需要进行的确认测试过程、策略和方法。
确认测试的具体执行还是在软件概要设计、详细设计、编写代码、单元测试、集成测试完成之后进行。也就是说，把单元测试、集成测试和确认测试都分解为相应的测试设计和测试执行两部分，测试设计前移到编码之前的对应阶段，测试执行在编码之后。这样可以迫使软件设计和开发人员更早地考虑软件合格的标准。
