软体工程的线性顺序模型，有时也称“传统生命周期”或“瀑布模型”，线性顺序模型提出了软体开发的系统化的、顺序的方法（虽然由Winston Royce[ROY70]提出的最早的瀑布模型支持带有反馈的循环，但大多数使用该过程模型的组织均把它视为是严格线性的），从系统级开始，随后是分析、设计、编码、测试和维护。

瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即採用结构化的分析与设计方法将逻辑实现与物理实现分开。将软体生命周期划分为制定计画、需求分析、软体设计、程式编写、软体测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

瀑布模型是最早出现的软体开发模型，在软体工程中占有重要的地位，它提供了软体开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。对于经常变化的项目而言，瀑布模型毫无价值。

因为软体总是一个大系统（或商业）的组成部分，所以一开始应该建立所有系统成分的需求，然后再将其中某个子集分配给软体。整个系统基础是，以软体作为其他成分如硬体、人及资料库的接口。系统工程和分析包括了系统级收集的需求，以及一小部分顶层分析和设计。信息工程包括了在战略商业级和商业领域级收集的需求。

需求收集过程特别集中于软体上。要理解待建造程式的本质，软体工程师（“分析员”）必须了解软体的信息领域以及需求的功能、行为、性能和接口。系统需求和软体需求均要文档化，并与用户一起複审。

设计：软体设计实际上是一个多步骤的过程，集中于程式的四个完全不同的属性上：数据结构、软体体系结构、界面表示及过程（算法）细节。设计过程将需求转换成软体表示，在编码之前可以评估其质量。象需求一样，设计也要文档化，并且是软体配置的一部分。

代码生成：设计必须转换成机器可读的形式。代码生成这一步就是完成这个任务的。如果设计已经表示得很详细，代码生成可以自动完成。

测试：一旦生成了代码，就可以开始程式测试。测试过程集中于软体的内部逻辑——保证所有语句都测试到，以及外部功能——即引导测试去发现错误，并保证定义好的输入能够产生与预期结果相同的输出。

维护：软体在交付给用户之后不可避免地要发生修改（一个可能的例外是嵌入式软体）。在如下情况下会发生修改：当遇到错误时；当软体必须适应外部环境的变化时（例如，因为使用新的作业系统或外设）；或者当用户希望增强功能或性能时。软体维护重複以前各个阶段，不同之处在于它是针对已有的程式，而非新程式。

1）阶段间的顺序性和依赖性，项目从开始到结束按照一定的顺序执行；瀑布模型是文档驱动的，各个阶段不连续也不交叉。

2）严格阶段评估，必须先进行一个阶段严格评估才能进入下一个阶段。

3）开发初期需要清楚全部需求。

4）开发周期长，风险大。

1）实际的项目大部分情况难以按照该模型给出的顺序进行，而且这种模型的叠代是间接的，这很容易由微小的变化而造成大的混乱。

2）很多情况下客户难以表达真正的需求，而这种模型却要求如此，这种模型是不“欢迎”具有二义性问题存在的。

3）客户要等到开发周期的末期才能看到程式运行的测试版本，而在这时发现大的错误时，可能引起客户的惊慌，而造成的后果也可能是灾难性的。

4）经常会在过程的开始和结束时碰到等待其他成员完成其所依赖的任务才能进行下去的情况，有可能花在等待的时间比开发的时间要长，称为“堵塞状态”。

1）它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

2）儘管有不少缺陷，但比在软体开发中呈现随意的状态要好得多。