存在问题：用户将原型认为是最终产品，开发者有时也不会坚持原则。
适用：它适合于那些不能预先确切定义需求的软件系统的开发，更适合于那些项目组成员（包括分析员、设计员、程序员和用户）不能很好交流或通信有困难的情况。
快速原型模型
又称原型模型，它是增量模型的另一种形式；它是在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。
优点：减少由于软件需求不明确带来的开发风险。
//（1）可以得到比较良好的需求定义，容易适应需求的变化；（2）有利于开发与培训的同//步；（3）开发费用低、开发周期短且对用户更友好。
缺点：所选用的开发技术和工具不一定符合主流的发展；快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。
//（1）客户与开发者对原型理解不同；（2） 准确的原型设计比较困难；（3） 不利于开发//人员的创新。
增量模型
增量模型是一种非整体开发的模型，分为两种形式：基于瀑布模型的渐增模型；基于原型的快速原型模型
增量模型的优点： （1）采用增量模型的优点是人员分配灵活，刚开始不用投入大量人力资源；（2）如果核心产品很受欢迎，则可增加人力实现下一个增量；（3）可先发布部分功能给客户，对客户起到镇静剂的作用。
缺点： （1）并行开发构件有可能遇到不能集成的风险，软件必须具备开放式的体系结构；
（2）增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性
增量模型和瀑布模型之间的本质区别是：瀑布模型属于整体开发模型，它规定在开始下一个阶段的工作之前，必须完成前一阶段的所有细节。而增量模型属于非整体开发模型，它推迟某些阶段或所有阶段中的细节，从而较早地产生工作软件。 增量模型的使用范围：
（1）进行已有产品升级或新版本开发，增量模型是非常适合的；（2）对完成期限严格要求的产品，可以使用增量模型；（3）对所开发的领域比较熟悉而且已有原型系统，增量模型也是非常适合的 循环模式
螺旋模型
将瀑布模型和增量模型结合起来，并加入了风险分析，按照计划-》风险分析-》工程-》用户评价，象螺旋线一圈一圈地向外发展，最终建立起运行的系统。主要分为四个工作步骤：
（1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件； （2）风险分析：分析评估所选方案，考虑如何识别和消除风险； （3）实施工程：实施软件开发和验证；
（4）客户评估：评价开发工作，提出修正建议，制定下一步计划。
优点：1）设计上的灵活性,可以在项目的各个阶段进行变更。 2）以小的分段来构建大型系统,使成本计算变得简单容易。 3）客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。
4）随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。 5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品
缺点：1）采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失。
2）过多的迭代次数会增加开发成本，延迟提交时间。
适应场合：支持需求不明确、特别是大型软件系统的开发，并支持面向规格说明、面向过程、面向对象等多种软件开发方法，是一种具有广阔前景的模型。
喷泉模型
?适用于面向对象技术
?该模型中各阶段的界线不是明显分开的，而是相互重叠的
是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。
优点：该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。
缺点：由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。
智能模型
也称为基于知识的软件开发模型，是知识工程与软件工程相结合的软件开发模型。其主要特点是必须建立知识库，并将模型本身、软件工程知识、特定领域知识放入知识库。具体描述可以使用形式功能规约，也可以使用知识处理语言描述等。
RUB模型
?适用于面向对象技术
?RUP将软件开发过程分为4个阶段: 初始阶段(Inception) 筹划阶段(Elaboration) 构建阶段(Construction)
转换阶段(Transition)
边做边改模型（Build-and-Fix Model）
在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改
这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：
（1） 缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；
（2） 忽略需求环节，给软件开发带来很大的风险；
（3） 没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。
黑盒测试（确认功能）：
指把测试对象看成一个黑盒子，测试人员完全不考虑程序的内部结构和处理过程，只在软件的接口处进行测试，依据需求规格说明书，检查程序是否满足功能要求，又称为功能测试或数据驱动测试。 优点：①适用于各阶段测试②从产品功能角度测试③容易入手生成测试数据
缺点：①某些代码得不到测试②如果规格说明有误，则无法发现③不易进行充分性测试 白盒测试（验证逻辑）：
指把测试对象看成一个打开的盒子，测试人员需了解程序的内部结构和处理过程，以检查处理过程的细节为基础，对程序中尽可能多的逻辑路径进行测试，检验内部控制结构和数据结构是否有错，实际的运行状态与预期的状态是否一致。 优点：①可构成测试数据使特定程序部分得到测试②有一定的充分性度量手段③可或较多工具支
缺点：①不易生成测试数据(通常)②无法对未实现规格说明的部分进行测试③工作量大，通常只用于单元测试，有应用局限
软件开发组织