软件生存期模型是跨越整个生存期的系统开发、运作和维护所实施的全部过程、活动和任务的结构框架
~瀑布模型
瀑布模型规定了各项软件工程活动，包括制定开发计划、需求分析和说明、软件设计、程序编码、测试和运行、维护，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
实践表明，上述各项活动之间并非完全是自上而下，呈线性图式。实际情况是，每项开发活动均应具有以下特征：
（1）从上一级活动接受本项活动的工作对象，作为输入；
（2）利用这一输入实施本项活动应完成的工作；
（3）给出本项活动的工作成果，作为输出传给下一项活动；
（4）对本项活动实施的工作进行评审，若其工作得到确认，则继续进行下一项活动，否则返回前一项活动，甚至更前的活动进行返工。
为了保证软件开发的正确性，每一阶段任务完成后，都必须对它的阶段产品进行评审，确认之后再转入下一阶段。如评审过程中发现错误和疏漏，应该返回前面的有关阶段修正错误、弥补漏洞，然后再重复前面的工作，直至该阶段的工作通过评审后再进入下一阶段。
严格按照软件生存周期阶段划分，顺序执行各阶段构成软件开发的瀑布模型，是传统的软件工程生存期模式。采用瀑布模型进行开发组织时，应指定开发规范或开发标准，其中要明确规定各个开发阶段应交付的产品，这为严格控制软件开发项目的进度，最终按时交付产品以及保证软件产品质量创造了条件。瀑布模型为软件开发和维护提供了一种有效的管理模式。
瀑布模型是非常经典的，它的的思想是：从制作时间上按工序把问题化简，将功能实现与制作分开，便于分工协作。
优点： 奠定了软件工程方法的基础；流水依赖，便于分工协作；推迟物理实现，易于修改文档，有复审质量保证。
不足：瀑布模型也存在很大的不足，这种方法开发的软件，与用户见面太晚，往往得到的成品，与用户的需求存在一定的差距。
适用范围：瀑布模型使用于系统要求明确的系统，各种应用软件的开发均可使用。
瀑布模型图如下：
~快速原型模型
快速原型模型克服了瀑布模型中系统分析员不了解用户的需求的缺点。它的基本思想是软件开发人员根绝用户提出的软件基本需求快速开发一个原型，以便向用户展示软件系统应有的部分或全部的功能和性能，在征求用户对原型的评价意见之后，进一步使需求精确化、完全化，并据此改进、完善原型，如此迭代，知道软件开发人员和用户都确认软件系统的需求并达成一致的理解为止。软件需求分析确定之后，便可进行设计、编码、测试等以后的各个开发步骤。可见，原型主要是为了完成需求分析阶段的任务而构建的。
快速原型的开发途径：
（1）仅模拟软件系统的人机界面和人机交互方式；
（2）开发一个工作模型，实现软件系统中重要的或容易产生误解的功能；
（3）利用一个或几个类似的正在运行的软件向用户展示软件需求中的部分或全部功能。
虽然用户和开发人员都非常喜欢原型，因为它能使用户能够感受到实际系统，开发人员能 很快建造一些东西。但是它也存在着一些问题：比如临时搭建的软件，并没有考虑软件的整体质量和今后的可维护性，当用户被告知该产品必须重建时，他们往往叫苦连天。
虽然会出现问题，原型模型仍是软件工程的一个有效典范。建立元习惯仅仅是为了定义需求，之后就该抛弃，实际的软件在充分考虑了质量和可维护性之后才被开发。它比瀑布模型更符合人们认识事物的过程和规律，是一种较实用的开发框架。它适合那些不能预先确切定义需求的软件系统的开发。
快速原型模型图如下：
~增量模型
增量模型规定软件的开发过程是一次开发产品的一个部分。首先应该开发产品的基本部分，然后再逐步开发产品的附加部分。为了使所开发的产品的各个部分最后能有机地组合起来，首先应该有一个统一的体系结构设计。
再改模型中，产品的设计、实现、集成和试验是以一系列增量构件为基础进行的，构件是由一些模块的编码构成并能提供特定的功能。
例如：在操作系统中，调度程序是一个构件，然后集成到先前已构成的产品中并作为一个整体进行测试，当这个产品满足规定的功能，即满足它的需求规范时，这个过程停止。开发者可以任意分解目标产品以得到一些构件，但是这些构件必须能集成为一个满足需要功能的产品。如果目标产品智能分解为很少的构件，那么增量模型可能退化为建造与修改模型。如果目标产品分解为太多的构件，那么每个阶段结束时，用户可能得不到需要的功能，并且有更多的时间浪费在集成上，因此构件的大小应适中，这取决于用户的需求。一个典型的产品通常由10-50个构件组成。
瀑布模型和快速原型模型都是提交完整的可操作质量的软件。客户希望交付的产品满足所有的需求，并且应该得到全面的和正确的文档，这些文档应该用于各种维护。但是客户得到其产品，必须等数月或者数年。
而增量型在每个阶段都交付一个可操作的产品，但是它仅仅满足客户需求的一个子集。完整的产品划分成一些构件，产品是一次一个构件的方式开发的。当使用增量模型时，第一个增量经常是核心产品，他满足用户的基本需求，而许多附加功能将在以后的增量中交付。当没有足够的人员在规定的 期限内开发完整的产品时，或者由于不可克服的客观原因而把交付期限规定得太短时，增量开发方式是特别有用的。
对于增量模型来说，它的开发的一个难点是后来开发的构件必须能够集成到先前已开发的产品中而不毁坏已开发的功能。进而，现存的产品必须容易扩充，后开发的构件必须是简单和直观并容易集成。因此，对于增量模型，产品的体系结构的设计必须是开放的。
增量模型图如下：
~螺旋模型
对于复杂的大型软件，开发一个原型往往达不到要求。螺旋模型将瀑布模型和原型模型结合起来，不仅体现了两个模型的优点，而且还增加了两个模型都忽略了的风险分析，弥补了两者的不足。
螺旋模型的结构由四部分组成：制定计划、风险分析、实施开发、客户评估。在迪卡儿坐标的四个象限上分别表达了四个方面的活动。
沿螺旋线自内向外每旋转一圈便开发出一个更为完善的新的软件版本。例如：在第一圈，在制定计划阶段，确定了初步的目标、方案和限制条件以后，转入风险分析阶段，对项目的风险进行识别和分析。如果风险分析表明，需求有不确定性，对需求做进一步的修改。软件开发完成之后，客户会对工程成果做出评价，给出修正建议。在此基础上进入第二圈螺旋，再次进行制定计划、风险分析、实施开发和客户评估等工作。假如风险过大，开发者和用户无法承受，项目有可能终止。多数情况下，软件开发过程是沿螺旋线的路径进行的，自内向外，逐步延伸，最终总能得到一个用户满意的软件版本。
如果软件开发人员对所开发项目的需求有了较好的理解，则无需开发原型。可采用普通瀑布模型。螺旋模型不仅保留了瀑布模型中系统地、按阶段逐步地进行软件开发和“边开发、边评审”的风格，而且还引入了风险分析，并把制作原型作为风险分析的主要措施。用户始终关心、参与软件开发，并对阶段性的软件产品提出评审意见，这对保证软件产品的质量十分有利。
但是，螺旋模型的使用需要具有相当丰富的风险评估经验和专门知识，而且费用昂贵，所以只适用大型软件开发。
螺旋模型图如下：
~喷泉模型
喷泉模型是近几年提出来的软件生存周期模型。它是以面向对象的软件开发方法为基础，以用户需求为动力，以对象来驱动的模型。喷泉模型的特点：
（1）整个开发过程（包括维护过程）包括5个阶段，即需求阶段、设计、实现、测试和维护。因此，使软件系统可维护性较好；
（2）各阶段相互重叠，表明了面向对象开发各阶段间的交叉和无缝过渡；
（3）整个模型是一个迭代的过程，包括一个阶段内部的迭代和跨阶段的迭代；
（4）模型具有增量开发特性，即能做到边分析，边设计；边实现，边测试，使相关功能随之加入到演化的系统中；
（5）模型是对象驱动的，对象是各阶段活动的主体，也是项目管理的基本内容；
（6）该模型很自然地支持软件部件的重用。
喷泉模型图如下：
