1）瀑布模型，
2）快速原型模型，
3）渐增模型，
4）演进模型。
下面我们重点阐述前3种常用的生命周期模型。
2．1瀑布模型
顾名思义，该模型就是像瀑布一样。这是一个最传统的生命周期模型，是一种顺序的模型，自顶向下把一个软件开发过程分为：系统定义、需求分析、设计、编码、 测试和维护等阶段。在开发过程中这些阶段顺序进行，就像是一个飞流直下的瀑布，因此得名。该模型可以用下面的图形来表示。
系统定义
\|/
需求分析
\|/
设计
\|/
编码
\|/
测试
\|/
维护
有时，根据项目的特点，设计又可分为概要设计和详细设计。
上图中各阶段所要完成的工作在一般的论述软件工程的书籍中都有描述，这里就不再细述。
虽然上面的阶段是顺序进行的，但是这并不是限定我们的软件项目必须在完成了上个阶段的工作后才能进行下个阶段的工作。在实际的开发过程中，我们常常会遇到这样的情况：阶段反复和重叠。
在前面的需求管理部分我们曾经阐述过需求变更管理。也就是说，在软件开发的某个阶段可能发生需求变更，而一旦软件需求发生变化，就势必会造成软件设计的改 变，因此，如果该软件项目已经进行到了测试阶段，那么我们就必须回过头来重新进行需求分析、概要设计、详细设计和编码。像这种在后面的阶段又返回来做前面 阶段工作的情形，就成为阶段反复。当然，也有可能因为开发人员前面的工作做得不够准确而导致阶段反复。阶段反复常常会造成进度延迟，但是，只要严格控制好 每个阶段的输入和输出，我们还是可以有效的控制软件项目的开发过程。
在实际的开发过程中我们还会遇到这种情况：如果一个软件项目规模较大，而 且各功能模块相对独立，那么，我们就没有必要要求所有模块的进度都一致，也就是说，模块1可能很快就能完成概要设计和详细设计，而模块2由于太复杂概要设 计可能就需要很长的时间。对于这种情况，只要控制好模块1各阶段的输入和输出，完全可以让模块1先行，直到完成或者必须停下来等待其他模块。像这种情况， 一个软件项目的各模块可能处于不同的阶段，就成为阶段重叠。出现这种情况，必须是某些模块比较独立，否则就不可能比其他模块先行。
虽然阶段的 重叠和反复是允许的，但是我们却不能允许这种情况随意发生。比如说，需求分析和设计可以重叠，但是如果需求分析和编码也重叠就很难说代码会写成什么样了； 编码阶段可以因为需求变更回过头来进行需求分析和设计，但是如果已经进行系统测试了还在进行阶段反复，这就等于又开发一个新项目了。因此，为了更好的控制 软件开发过程，要尽量减少阶段重叠和反复，如果实在不可避免，应该对所有的变更进行严格控制，这样才能保证我们的开发过程陷入无序状态。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
