软件研发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。 软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。对于不同的软件系统，可以采用不同的开发方法、使用不同的程序设计语言以及各种不同技能的人员参与工作、运用不同的管理方法和手段等，以及允许采用不同的软件工具和不同的软件工程环境。
软件研发模型类型
1、瀑布模型（Waterfall Model）
瀑布模型（Waterfall Model） 是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品。因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。
核心思想
瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
瀑布模型有以下优点
1）为项目提供了按阶段划分的检查点。
2）当前一阶段完成后，您只需要去关注后续阶段。
3）可在迭代模型中应用瀑布模型。
增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。
4）它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
瀑布模型有以下缺点
1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4）瀑布模型的突出缺点是不适应用户需求的变化。
2、边做边改模型（Build-and-Fix Model）
当一个软件产品在没有规格说明或主要设计的情况下被开发时，开发者往往不得不重新对产品编码多次直到他们得到正确稳定的产品。这种开发模型就是边做边改模型。
开发者们首先开发出一个产品的最初版本给客户验收，然后开发团队开发一个新的版本再次给客户验收。这个过程一直持续到客户感觉产品满意为止。
边做边改型的缺点：
边做边改模型的最重要缺点是存在于需求。设计和实现中的错误要到整个产品被构建出来后才能被发现。
这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：
1） 缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；
2） 忽略需求环节，给软件开发带来很大的风险；
3） 没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。
3、大爆炸模型
一大堆东西（人力和资金）放在一起，巨大的能量释放，要么产生了优秀的产品，要么是一堆废品。大爆炸模式是最简单的软件开发模式，计划、进度安排和正规开发过程都几乎没有，所有精力都花在开发软件和编写代码上；
一般，大爆炸模式几乎没有测试，即使有也要挤在产品发布前，通常都会避免在此模式下进行测试。
4、螺旋模型（Spiral Model）
螺旋模型（Spiral Model）1988年，Barry Boehm（巴利·玻姆）提出。开始不必详细定义所有细节，从小开始，定义重要功能，努力实现这些功能，接收客户反馈，然后进入下一阶段，重复上述过程，直至得到最终产品。正所谓计划赶得上变化。特别适合于大型复杂系统。
“螺旋模型”刚开始规模很小，当项目被定义得更好、更稳定时，逐渐展开。对于新近开发，需求不明确的情况下，适合用螺旋模型进行开发，便于风险控制和需求变更。
“螺旋模型”的核心就在于您不需要在刚开始的时候就把所有事情都定义的清清楚楚。您轻松上阵，定义最重要的功能，实现它，然后听取客户的意见，之后再进入到下一个阶段。如此不断轮回重复，直到得到您满意的最终产品。
螺旋模式中包含了一点瀑布模式（分析、设计、开发和测试的步骤）、一点边写边改模式（螺旋模式的每一次）和一点大爆炸模式（从外界观察）。加上该模式发现问题早、成本低的特点，可以算做相当好的开发模式。因为通过参与最初设计的设计阶段，可以尽早地影响到产品，可以把产品的来龙去脉弄得很清楚；并且在项目末期，不至于最后一分钟还在匆匆忙忙地进行全面测试。软件测试员地测试一直都在进行，所以最后一步只是一个验证表面所有部分都没有问题。
一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段。
螺旋模型的优缺点：
优点
1）设计上的灵活性,可以在项目的各个阶段进行变更。
2）以小的分段来构建大型系统,使成本计算变得简单容易。
3）客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。
4）随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。
5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。
缺点
很难让用户确信这种演化方法的结果是可以控制的。建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。
5、迭代开发模型
迭代模型是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实质上，迭代模型是类似小型的瀑布式项目。
适用项目： 适合于事先不能完整定义产品的所有需求，计划多期开发的项目。
每一个迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。 一次迭代过程包括了所有软件开发流程，每一次迭代均产生一个可发布的产品，该产品为最终产品的一个子集。
每次迭代成果须进行配置管理，版本控制很重要。在整个迭代过程中风险无处不在，建议每周作一次风险跟踪。同时通过重点关注进度、工作量、满意度、缺陷等数据收集，关注每次迭代情况。
迭代开发模型优点
与传统的瀑布模型相比较，迭代过程具有以下优点：
1）降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。
2）降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。
3）加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。
4）由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。
选择一个合适的生命周期模型，并应用正确的方法，对于任何软件项目的成功是至关重要。企业在选择开发模型应从项目时间要求、需求明确程度、风险状况等选择合适的生命周期模型。
6、增量模型（Incremental Model）
增量模型又称为渐增模型，也称为有计划的产品改进模型，它从一组给定的需求开始，通过构造一系列可执行中间版本来实施开发活动。第一个版本纳入一部分需求，下一个版本纳入更多的需求，依此类推，直到系统完成。每个中间版本都要执行必需的过程、活动和任务。
增量模型是瀑布模型和原型进化模型的综合，它对软件过程的考虑是：在整体上按照瀑布模型的流程实施项目开发，以方便对项目的管理；但在软件的实际创建中，则将软件系统按功能分解为许多增量构件，并以构件为单位逐个地创建与交付，直到全部增量构件创建完毕，并都被集成到系统之中交付用户使用。
采用随时间进展而交错的线性序列。每个序列产生一个可发布的增量。每一个增量产生一个可操作的产品。第一个增量是核心产品。
优点： 开始时不用投入大量人力资源，可以事先推出核心产品以稳定用户，可以有计划的管理技术风险。
缺点： 需要开放式体系结构，可能会产生设计效果差、开发效率低的情况。
适合项目： 需求经常发生改变的软件开发过程。
增量和迭代模型的区别：
增量是逐块建造的概念，例如：画一幅人物画，我们可以先画人的头部，再画身体，再画手脚……。
迭代是反复求精的概念，例如：同样是画人物画，我们可以先画整体轮廓，在勾勒出基本雏形，再细化、着色……。
7、敏捷开发模型（Agile software development）
是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于"非敏捷"，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。
敏捷开发的核心思想是：以人为本，适应变化。
敏捷开发提倡迭代式和增量式的开发模式，并强调测试在其中的重要作用。敏捷开发是以用户为中心、以客户需求为导向的开发过程，在此过程中随时做好“迎接变化”的准备，客户是敏捷的关键环节。敏捷开发没有单一固定的开发方法或过程，很多快速的开发模式都可以看作是敏捷。但这些模式都有三个共同点：依赖客户的参与、测试驱动以及紧凑的迭代开发周期。
如果要实行一个很好的scrum,通常要满足两点：一、团队有三名或以上的研发工程师；二、团队内有一名合适的Scrum Master。当团队内无法找到合适的Scrum Master时，不要轻易推行敏捷。如果你的团队是由新人组成，或者即使有资深员工但是他并不了解或认同敏捷开发的话，那么你需要等待合适的Scrum Master出现。
当你真正实行敏捷开发时，要注意量化衡量团队的执行力的指标：完成度、评估准确度、计划合理度。这是评定整个进度的很重要的指标，也是让迭代更好的进行下去的准则。