软件生命周期是指从软件定义、开发、使用、维护到报废为止的整个过程，一般包括问题定义、可行性分析、需求分析、总体设计、详细设计、编码、测试和维护。

问题定义就是确定开发任务到底“要解决的问题是什么”，系统分析员通过对用户的访问调查，最后得出一份双方都满意的关于问题性质、工程目标和规模的书面报告。

可行性分析就是分析上一个阶段所确定的问题到底“可行吗”，系统分析员对系统要进行更进一步的分析，更准确、更具体地确定工程规模与目标，论证在经济上和技术上是否可行，从而在理解工作范围和代价的基础上，做出软件计划。

需求分析即使对用户要求进行具体分析，明确“目标系统要做什么”，把用户对软件系统的全部要求以需求说明书的形式表达出来。

总体设计就是把软件的功能转化为所需要的体系结构，也就是决定系统的模块结构，并给出模块的相互调用关系、模块间传达的数据及每个模块的功能说明。

详细设计就是决定模块内部的算法与数据结构，也是明确“怎么样具体实现这个系统”。

编码就是选取适合的程序设计语言对每个模板进行编码，并进行模块调试。

测试就是通过各种类型的测试使软件达到预定的要求。

维护就是软件交付给用户使用后，对软件不断查错、纠错和修改，使系统持久地满足用户的需求。

软件的生命周期也可以分为3个大的阶段，分别是计划阶段、开发阶段和维护阶段。

软件生命周期模型也称为软件过程模型，反映软件生存周期各个阶段的工作如何组织、衔接，常用的有瀑布模型、原型模型、螺旋模型、增量模型、喷泉模型，还有建造-修补模型、MSF过程模型、快速原型模型。[1]

瀑布模型

有时也称为V模型，它是一种线型顺序模型，是项目自始至终按照一定顺序的步骤从需求分析进展到系统测试直到提交用户使用，它提供了一种结构化的、自顶向下的软件开发方法，每阶段主要工作成果从一个阶段传递到下一个阶段，必须经过严格的评审或测试，以判定是否可以开始下一阶段工作，各阶段相互独立、不重叠。瀑布模型是所有软件生命周期模型的基础。[1]

原型+瀑布模型

原型模型本身是一个迭代的模型，是为了解决在产品开发的早期阶段存在的不确定性、二义性和不完整性等问题，通过建立原型使开发者进一步确定其应开发的产品，使开发者的想象更具体化，也更易于被客户所理解。原型只是真实系统的一部分或一个模型，完全可能不完成任何有用的事情，通常包括抛弃型和进化型两种，抛弃型指原型建立、分析之后要扔掉，整个系统重新分析和设计；进化型则是对需求的定义较清楚的情形，原型建立之后要保留，作为系逐渐增加的基础，采用进化型一定要重视软件设计的系统性和完整性，并且在质量要求方面没有捷径，因此，对于描述相同的功能，建立进化型原型比建立抛弃型原型所花的时间要多。原型建立确认需求之后采用瀑布模型的方式完成项目开发。[1]

增量模型

与建造大厦相同，软件也是一步一步建造起来的。在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。

一些大型系统往往需要很多年才能完成或者客户急于实现系统，各子系统往往采用增量开发的模式，先实现核心的产品，即实现基本的需求，但很多补充的特性(其中一些是已知的，另外一些是未知的)在下一期发布。增量模型强调每一个增量均发布一个可操作产品，每个增量构建仍然遵循设计-编码-测试的瀑布模型。[1]

迭代模型

早在20世纪50年代末期，软件领域中就出现了迭代模型。最早的迭代过程可能被描述为“分段模型”。迭代，包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。

实质上，它类似小型的瀑布式项目。所有的阶段（需求及其它）都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。