瀑布模型
在瀑布模型中，开发过程是线性的。任务和阶段按严格顺序一个接一个地完成。进度平稳地向下流动，就像瀑布上的水一样。
将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动。
优点
1、每个阶段的开发质量都有保证，减少了返工。2、是文档细致，降低了沟通成本，有利于及早发现问题。
缺点
周期长，不易变更
不灵活（开发过程一般不能逆转，否则代价太大，如果项目是长期的，且正在进行的，此模型不行）
瀑布模型是由文档驱动，在可运行的软件产品交付给用户之前，用户只能通过文档来了解产品是什么样的。瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要。不适合需求模糊的系统。
使用范围
用户的需求非常清楚全面，且在开发过程中没有或很少变化,对软件的应用领域很熟悉；用户的使用环境非常稳定；开发工作对用户参与的要求很低。
不适合需求模糊或需求经常变动的系统
补充
按照瀑布模型的阶段划分，软件测试可以分为单元测试，集成测试，系统测试
V型模型
V模型其实是瀑布模型的变种，反映了软件测试活动与软件开发过程(从分析到设计)的关系
优点
清楚的标识了开发和测试的各个阶段；自上而下逐步求精，每个阶段分工明确，便于整体项目的把控。
缺点
由于它的顺序性，当编码完成之后，正式进入测试时，这时发现的一些bug可能不容易找到其根源，并且代码修改起来很困难。
实际中，由于需求变更较大，导致要重复变更需求、设计、编码、测试。返工量大。
迭代模型
使用条件
适合于事先不能完整定义产品的所有需求，计划多期开发的项目。
高风险项目，且需求不确定，用户能在整个开发过程中不同程度地参与。
1、在项目开发早期需求可能有所变化。
2、分析设计人员对应用领域很熟悉。
3、高风险项目。
4、用户可不同程度地参与整个项目的开发过程。
优点
降低了产品无法按照既定进度进入市场的风险。
加快了整个开发工作的进度。
缺点
风险管理成本较高，在风险分析，进度管理方面，对项目组成员的要求也非常高。
增量模型
增量模型也称渐增模型。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能
适用场合
适应于需求经常改变的软件开发过程
i. 用户核心需求非常清楚；ii. 项目人员不足；iii. 产品可以分割成不同的阶段分别完成
优点
开始时不用投入大量人力资源，可以事先推出核心产品以稳定用户，可以有计划的管理技术风险。
能在较短的时间内向用户提交可完成部分工作的产品
将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展
以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统
开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时地对实现顺序进行调整
1、在达到初始需求之前可降低成本。2、可快速生产出可使用的系统。 3、能够有计划地管理技术风险。
缺点
需要开放式体系结构，可能会产生设计效果差、开发效率低的情况。
螺旋模型
螺旋模型是一种演化软件开发过程模型，它兼顾了快速原型的迭代特征以及瀑布模型的系统化与严格监控。螺旋模型最大的特点在于引入了风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。同时，在每个迭代阶段构建原型是螺旋模型用以减小风险的途径
适用场合
特别适用于庞大、复杂并具有高风险的系统
对新近开发，需求不明确的情况下，适合用螺旋模型进行开发，便于风险控制和需求变更。
优点
强调各个开发阶段的质量
减少了过多测试（浪费资金）或测试不足（产品故障多）所带来的风险
缺点
采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失
过多的迭代次数会增加开发成本，延迟提交时间
软件建设周期长，但软件技术发展比较快，所以可能会和当前的技术水平有较大的的差距，无法满足当前用户需求。
由于引入了非常严格的风险识别、风险分析和风险控制，将会大大消耗人力、资源，如果严重的影响了项目的利润，风险分析将毫无意义。
大爆炸模型
Big Bang 模型通常不遵循任何特定过程或说明。开发从当前可用的资源和工作开始，几乎没有计划或根本没有计划。结果，客户得到的产品甚至可能无法满足要求。功能是动态实现的。
Big Bang SDLC 模型的主要思想是将所有可用资源分配给产品本身的开发，主要是在编码方面，而不用担心满足计划。这是仅用于一两个软件工程师的小型项目的 SDLC 方法之一。
敏捷模型
定义
一种以人为核心、快速迭代、循序渐进的开发方法。强调以人为本，专注于交付对客户有价值的软件。是一个用于开发和维持复杂产品的框架。就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
适用场合
适合于中小型开发团队，客户需求模糊或多变。
强调人与人之间的沟通。
轻文档（弱化文档，但不是不需要文档）
客户需要全程参与
需求可以的变化
优点
敏捷确实是项目进入实质开发迭代阶段，用户很快可以看到一个基线架构版的产品。敏捷注重市场快速反应能力，也即具体应对能力，客户前期满意度高。
可以促进跨部门的合作及更优的反馈机制
缺点
但敏捷注重人员的沟通，忽略文档的重要性，若项目人员流动大太，又给维护带来不少难度，特别项目存在新手比较多时，老员工比较累。需要项目中存在经验较强的人，要不大项目中容易遇到瓶颈问题。
原型模型
原型模型要求在进行实际软件开发之前，应建立系统的工作原型。
原型通常是实际系统的一个非常粗糙的版本，与实际软件相比，可能表现出有限的功能能力、低可靠性和低效的性能。
在许多情况下，客户只能对软件产品的期望有一个大致的了解。在没有关于系统输入、处理需求和输出需求的详细信息的这种情况下，可以使用原型模型。
适用场景
i 处理简单过程明确、涉及面窄的小型系统；ii 大型系统的需求阶段，用原型去跟用户交流，需求分析会更加明确和细化
优点
支持早期产品营销
降低维护成本
由于系统是并排的，因此可以更早地检测到错误
缺点
一个不稳定/执行不善的原型通常会成为最终产品
花费大
很难知道该项目将持续多久
耗时长
W模型
开发一个v；测试一个v组合起来的模型（w模型也叫双v模型）
优点
将测试贯穿到整个软件的生命周期中，且除了代码要测试，需求、设计等都要测试。
更早的介入到软件开发中，能尽早的发现缺陷进行修复。
测试与开发独立起来，并与开发并行。
分阶段工作，方便项目整体管理。
缺点
对有些项目，开发过程中根本没有文档产生，故W模型无法使用。
对于需求和设计的测试技术要求很高，实践起来很困难。
不能适用于需求变更频繁的项目
总结
各模型项目特点
瀑布模型——文档驱动型
迭代模型——风险驱动型
增量模型——任务驱动型
原型模型——需求驱动型
瀑布模型
强调开发工作（计划、设计、开发、测试、维护等）各阶段之间的先后顺序，不可以并行操作。
迭代模型
与瀑布模型不同，不再强调开发工作的序列化过程，而是将这些过程并行化，分为多个阶段，每个阶段都包含这些工作，只是不同阶段，不同的比例。
v模型
强调将测试和开发同等重要，对于开发阶段都有与之对应的测试阶段。
原型化模型
强调产品以用户为中心，先开发出原形，和用户进行持续沟通，最终确定需求，并设计出最终的产品。
敏捷开发模型
强调以人为核心，这点和原型化模型很像，但是更强调程序员团队和业务专家之间的紧密联系，频繁交付新的软件版本，紧凑的自我组织型团队，更注重软件开发中人的作用。
螺旋模型
强调的是风险，面对大型、复杂的项目，采用这种方式，要根据需求，制定计划，风险分析，设计原型，客户评估，这四个阶段不断重复。不断地增量发布，针对每次的原型或者产品不断的进行风险评估，及时调整方案、需求、设计，以此迭代方式，最终完成产品。 强调的是产品从小到大，不断改进，不断风险分析的过程。虽然有迭代，但角度与迭代模型不一样，虽然用原型，但侧重点不是用户需求分析，而是风险分析，风险不仅仅来源于需求。
基本软件开发模型：瀑布模型 V型模型 迭代模型 增量模型 螺旋模型 大爆炸模型 敏捷模型 原型模型 W模型 特点分析与总结
如果觉得《基本软件开发模型：瀑布模型 V型模型 迭代模型 增量模型 螺旋模型 大爆炸模型 》对你有帮助，请点赞、收藏，并留下你的观点哦！
