软件开发模型
鉴于软件测试在面试阶段总是提及软件开发模型的缘故,于是粗略的总结一下软件开发模型,请指正!
软件开发模型是软件开发的全部过程、活动和任务的结构框架。软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目开发的基础。典型的开发模型有：①瀑布模型(waterfall model)；②渐增模型/演化/迭代(incremental model)；③原型模型(prototype model)；④螺旋模型(spiral model)；⑤)RAD模型(rap application development
)
瀑布模型将软件生命周期的各项活动规定为依固定顺序联接的若干阶段工作，形如瀑布流水，最终得到软件产品。
优点：
a.强调开发的阶段性；
b.强调早期计划及需求调查；
c.强调产品测试。
缺点：
a.依赖于早期进行的唯一一次需求调查，不能适应需求的变化；
b.由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程；
c.风险往往迟至后期的开发阶段才显露，因而失去及早纠正的机会。
演化模型主要针对事先不能完整定义需求的软件开发。用户可以给出待开发系统的核心需求，并且当看到核心需求实现后，能够有效地提出反馈，以支持系统的最终设计和实现。软件开发人员根据用户的需求，首先开发核心系统。当该核心系统投入运行后，用户试用之，完成他们的工作，并提出精化系统、增强系统能力的需求。软件开发人员根据用户的反馈，实施开发的迭代过程。第一迭代过程均由需求、设计、编码、测试、集成等阶段组成，为整个系统增加一个可定义的、可管理的子集。
在开发模式上采取分批循环开发的办法，每循环开发一部分的功能，它们成为这个产品的原型的新增功能。于是，设计就不断地演化出新的系统。 实际上，这个模型可看作是重复执行的多个“瀑布模型”。
“演化模型”要求开发人员有能力把项目的产品需求分解为不同组，以便分批循环开发。这种分组并不是绝对随意性的，而是要根据功能的重要性及对总体设计的基础结构的影响而作出判断。有经验指出，每个开发循环以六周到八周为适当的长度。
螺旋模型基本的做法是在“瀑布模型”的每一个开发阶段之前，引入非常严格的风险识别、风险分析和风险控制。直到采取了消除风险的措施之后，才开始计划下一阶段的开发工作。否则，项目就很可能被取消。
另外，如果有充足的把握判断遗留的风险已降低到一定的程度，项目管理人员可作出决定让余下的开发工作采用另外的生命周期模型，如“演化模型”，“瀑布模型”，或自定的混合模型。
优点：
a.强调严格的全过程风险管理。
b.强调各开发阶段的质量。
c.提供机会检讨项目是否有价值继续下去。
缺点：
a.引入非常严格的风险识别，风险分析，和风险控制，这对风险管理的技能水平提出了很高的要求。这需要人员，资金，和时间的投入。
螺旋模型是瀑布模型与演化模型相结合，并加入两者所忽略的风险分析所建立的一种软件开发模型。该模型于1998年由美国TRW公司（B.W.Boehm）提出。软件项目风险的大小作为指引软件过程的一个重要因素，引入这一概念有可能使得软件开发被看作一种元模型，因为它能包容任何一个开发过程模型。
快速原型是指 在进行了基本需求分析之后，快速开发出产品的原型，然后基于这个原型，同客户沟通、交流，更好地了解客户需求，不断修改这个原型，到了双方认可的程度，再做详细地分析、设计和编程，最终开发出令客户满意的产品。
一般步骤如下：
–(1) 先定义软件的总体目标，根据已知的需求来规划出可实现的区域。
–(2) 然后是“快速设计”，集中于系统的总体框架、基本功能和直观的输入方式和输出格式等。
–(3) 有了原型，使客户对系统实现哪些具体功能、功能实现到什么程度有更好的理解。开发者可以边开发边评估，不断细化软件的需求，逐步调整原型使其满足客户的要求。这形成一个迭代的过程。
即使开始建立的原型过于简单或性能很差，难以使用，但为下一次建立适用的模型积累了经验，而浪费的成本、时间有限。
原型模型的优点是使用户能够感受到实际的系统，使开发者能够快速地构造出系统的框架。
原型模型的缺点是产品的先天性不足，因为开发者常常需要做实现上的折中，可能采用不合适的操作系统或程序设计语言，以使原型能够尽快工作。
RAD模型
RAD（rap application development）模型，即快速应用开发模型。由于其模型构图形似字母“V”，故也称V模型，是属于线性顺序一类的软件开发模型。它通过使用基于构件的开发方法来缩短产品开发的周期，提高开发的速度。RAD模型实现的前提是能做好需求分析，并且项目范围明确，这一点正好和原型模型相反。
RAD模型还有一种改进型，将“编码”从V字型的顶点移到左侧，和单元测试对应，从而构成水平的对应关系。
从水平对应关系看
左边是设计和分析，右边是验证和测试。右边是对左边结果的检验，即对设计和分析的结果进行测试，以确认是否满足用户的需求。如：
需求分析和功能设计对应验收测试，说明在做需求分析、产品功能设计的同时，测试人员就可以阅读、审查需求分析的结果，从而了解产品的设计特性、用户的真正需求，可以准备用例（use case）。
当系统设计人员在做系统设计时，测试人员可以了解系统是如何实现的，基于什么样的平台，这样可以事先准备系统的测试环境，包括硬件和第三方软件的采购。因为这些准备工作，实际上要很长时间才能完成。
在做详细设计时，测试人员就可以准备测试用例（test case，以有效地发现软件缺陷的最小测试执行单元）。
一面编程，一面进行单元测试，是一种很有效的办法，使我们可以尽快找出程序中的错误。充分的单元测试可以大幅度提高程序质量、减少成本。
从图可以看出，RAD模型避免了瀑布模型所带来的误区——软件测试是在代码完成之后进行。RAD模型说明软件测试的工作很早就可以开始了，项目一启动，软件测试的工作也就启动了。
从垂直方向看
水平虚线上部表明，其需求分析、功能设计和验收测试等主要工作是面向用户，要和用户进行充分的沟通和交流，或者是和用户一起完成。水平虚线下部的大部分工作，相对来说，都是技术工作，在开发组织内部进行，由工程师完成。
所以RAD模型一般适合信息系统应用软件的开发，而不适合高性能、技术风险高或不易模块化的系统开发。如果一个系统难以被适当地模块化，那么就很难建立RAD所需的构件；如果系统具有高性能的指标，且该指标必须通过调整接口使其适应系统构件才能达到，使用RAD方法可能会导致整个项目失败。
