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