软件生命周期模型有瀑布模型、V模型、增量模型、原型模型、螺旋模型、喷泉模型、快速应用开发RAD模型、渐近式阶段模型、敏捷开发模型、软件包模型、遗留系统维护模型等。下面介绍几个常用的软件生命周期模型。

1．瀑布模型（Waterfall Model）

瀑布模型（见图2-13）是一个经典的软件生命周期模型，也称预测型生命周期或完全计划驱动型生命周期。在这个模型里，在项目生命周期的前期阶段，要确定项目范围及交付此范围所需的时间和成本。

图2-13　瀑布模型

该一般将软件开发分为可行性分析（计划）、需求分析、软件设计（概要设计、详细设计）、编码（含单元测试）、测试、运行维护等几个阶段。

瀑布模型适合的项目：在项目开始前，项目的需求和解决方案都很明确的项目。如短期项目。

瀑布模型中每项开发活动具有以下特点：

（1）从上一项开发活动接受其成果作为本次活动的输入。

（2）利用这一输入，实施本次活动应完成的工作内容。

（3）给出本次活动的工作成果，作为输出传给下一项开发活动。

（4）对本次活动的实施工作成果进行评审。若其工作成果得到确认，则继续进行下一项开发活动；否则返回前一项，甚至更前项的活动。尽量减少多个阶段间的反复，降低开发成本。

瀑布模型也有以下不足之处：

（1）在项目各个阶段之间极少有反馈。

（2）只有在项目生命周期的后期才能看到结果。

（3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。

2．V模型（V-shaped）

V模型（见图2-14）的左边下降部分是开发过程各阶段，与此相对应的是右边上升的部分，是各测试过程的各个阶段。在不同的组织中对测试阶段的命名可能有所不同。

图2-14　V模型

在模型图中的开发阶段一侧，先从定义业务需求、需求确认或测试计划开始，把这些需求转换到总体设计、总体设计的验证及测试计划，将总体设计进一步分解到详细设计、详细设计的验证及测试计划，最后进行开发，得到程序代码和代码测试计划。接着是测试执行阶段一侧，执行先从单元测试开始，然后是集成测试、系统测试和接收测试。

V模型适合的项目：在项目开始前，项目的需求和解决方案都很明确的项目；对系统的性能安全要求严格的项目。如航天飞机、公司的财务系统等。

V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发各阶段的对应关系：

（1）单元测试的主要目的是针对编码过程中可能存在的各种错误，例如用户输入验证过程中的边界值的错误。

（2）集成测试主要目的是针对详细设计中可能存在的问题，尤其是检查各单元与其他程序接口上可能存在的错误。

（3）系统测试主要针对总体设计，检查系统作为一个整体是否有效地得到运行，例如在产品设置中是否能达到预期的高性能。

（4）验收测试通常由业务专家或用户进行，以确认产品能真正符合用户业务上的需要。在不同的开发阶段，会出现不同类型的缺陷和错误，所以需要不同的测试技术和方法来发现这些缺陷。

3．原型模型（Prototyping）

原型模型是为弥补瀑布模型的不足而产生的。

原型模型（见图2-15）的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，经过和用户针对原型的讨论和交流，弄清需求以便真正把握用户需要的软件产品是什么样的。充分了解后，再在原型基础上开发出用户满意的产品。

图2-15　原型模型

在实际中原型模型经常在需求分析定义的过程进行。原型模型减少了瀑布模型中因为软件需求不明确而给开发工作带来的风险，因为在原型基础上的沟通更为直观，也为需求分析和定义提供了新的方法。原型化模型的应用意义很广，瀑布模型和V模型将原型化模型的思想用于需求分析环节，来解决因为需求不明确而导致产品出现严重后果的缺陷。

原型模型适合的项目：在项目开始前，项目的需求不明确的项目；用户无信息系统经验的项目；需求分析人员技能不足，不利于与客户交流的项目；交互性要求高的项目。如网站开发、科研项目等。

4．螺旋模型（Spiral）

螺旋模型（见图2-16）是瀑布模型、原型模型的有机结合，同时增加了风险分析。螺旋线代表随着时间推进的工作进展，开发过程具有周期性。4个象限分别标志每个周期所划分的4个阶段：制订计划、风险分析、实施工程和客户评论。螺旋模型强调了风险分析，特别适用于庞大而复杂的、高风险的系统。

图2-16　螺旋模型

螺旋模型适合的项目：客户始终参与每个阶段的开发，保证了项目不偏离正确方向，保证了项目的可控；适合于需求动态变化，事先难以确定并且开发风险较大的系统；大型复杂的系统。如企业资源计划管理系统（ERP）。

5．增量模型

增量模型（见图2-17）也称渐增模型。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。使用增量模型时，第一个增量构件往往实现软件的基本需求，提供最核心的功能。

图2-17　增量模型

把软件产品分解成增量构件时，应该使构件的规模适中，规模过大过小都不好。最佳分解方法因软件产品特点和开发人员的习惯而异。分解时唯一必须遵守的约束条件是，当把新的构件集成到现有软件中时，所形成的产品必须是可测试的。

增量模型的使用范围：

（1）进行已有产品升级或新版本开发。

（2）对完成期限严格要求的产品。

（3）对所开发的领域比较熟悉而且已有原型系统。

增量模型的缺点：

（1）并行开发构件有可能遇到不能集成的风险，软件必须具备开放式的结构。

（2）增量模型的灵活性可以使项目适应变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。

6．迭代式模型

迭代模型（见图2-18）是RUP（Rational Unified Process，统一软件开发过程或统一软件过程）推荐的周期模型。在RUP中，迭代被定义为：迭代包括生产到产品发布（稳定、可执行的产品版本）的全部开发活动和要实现发布必须的所有其他外围元素。所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实质上，它类似小型的瀑布式项目。RUP认为，所有的阶段（需求及其他）都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。迭代的思想如图2-18所示。

图2-18　迭代式模型

迭代和瀑布的最大的差别就在于风险的暴露时间上。任何项目都会涉及一定的风险。有许多风险直到已准备集成系统时才被发现，如果能在生命周期中尽早避免风险，那么计划自然会更趋于精确，但不管开发团队经验如何，都绝不可能预知所有的风险。由于瀑布模型的特点，很多的问题在最后才会暴露出来，为了解决这些风险花费是巨大的。在迭代式生命周期中，需要根据主要风险列表选择要在迭代中开发的新的增量内容。每次迭代完成时都会生成一个经过测试的可执行文件，这样就可以核实是否已经降低了目标风险。

7．喷泉模型

喷泉模型（见图2-19）是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。该模型认为软件开发过程是自下而上周期进行的，各阶段是相互迭代和无间隙的。

图2-19　喷泉模型

喷泉模型主要用于采用面向对象技术的软件开发项目。软件的某个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分。无间隙指在各项活动之间无明显边界，如分析和设计活动之间没有明显的界线，由于对象概念的引入，表达分析、设计、实现等活动只用对象类和关系，从而可以较为容易地实现活动的迭代和无间隙，使其开发自然地包括复用。

以喷泉模型为基础，可以尽早地实现全面的展开测试，同时将测试工作进行迭代。另外，改进的喷泉将需求纳入，使得模型完全实现了整个开发过程的无边界与交互性。

该模型每一次测试过程包括4个阶段：

第1阶段为测试需求阶段，包括提取和验证需求。这一阶段的测试主要是采用静态测试。

第2阶段为测试分析阶段，又分为制订测试计划、测试设计与开发两个步骤。测试计划包括确定测试策略和测试系统，预估测试工作量等。测试设计与开发包括开发测试用例，验证并调试测试等。

第3阶段为测试执行阶段，强调测试人员和开发人员的配合。该阶段的测试方法包括单元测试、集成测试、系统测试及验收测试。除了对程序进行测试外，还要对文档等进行测试。记录测试结果并写出测试总结报告，为下一轮的迭代测试打下基础。

第4阶段为测试维护阶段。开发者的维护包括修复顾客操作和为满足不断变化的顾客需求而对产品功能进行增强时发现的缺陷；测试组的维护意味着对缺陷的修复进行验证，测试增强的功能以及产品的新发布版本运行回归测试，以确保修改前的产品具有的功能不因产品的新变化而被破坏。

喷泉模型的优点：喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界线，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。

喷泉模型的缺点：由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。(www.daowen.com)

8．RAD模型

RAD（Rapid Application Development，快速应用开发，见图2-20）模型是增量型的软件开发过程模型，强调极短的开发周期，是瀑布模型的一个“高速”变种，通过大量使用可复用构件，采用基于构件的建造方法进行快速开发。

图2-20　RAD模型

如果正确地理解了需求，而且约束了项目范围，利用该模型可以很快开发出功能完善的软件系统。流程从业务建模开始，随后是数据建模、过程建模、应用生成、测试交付。

与瀑布模型相比，RAD模型不采用传统的第三代程序设计语言来创建软件，而是采用基于构件的开发方法，复用已有的程序结构，使用、创建可复用构件，并使用自动化工具辅助软件开发。RAD模型项目上的时间约束需要“一个可伸缩的范围”。如果一个业务能够被模块化并使得其中每一个主要功能均可以在不到三个月的时间内完成，则是RAD的一个候选。每一个主要功能可由一个单独的RAD组来实现，最后集成起来形成一个整体。

各个阶段完成的任务如下：

（1）业务建模。确定驱动业务过程运作的信息、欲生成的信息，如何生成信息流的去向及其处理等，可以辅之以数据流图。

（2）数据建模。为支持业务过程的数据流查找定义数据对象集合、属性，并与其他数据对象的关系构成数据模型，可辅之以E-R图。

（3）过程建模。使数据对象在信息流中完成各业务功能，创建过程以描述数据对象的增加、修改、删除、查找，即细化数据流图中的处理。

（4）应用生成，即应用程序生成。利用第四代语言（4GL）写出处理程序，重用已有构件或创建新的可重用构件，利用环境提供的工具自动生成以构造出整个应用系统。

（5）测试交付，即包含测试与交付两个过程。由于大量重用，一般只做总体测试，但新创建的构件要进行其他测试。测试完成后进行系统集成，然后交付用户使用。

RAD模型通过大量使用可复用构件加快了开发速度，对软件项目开发特别有效。但是与所有其他软件过程模型一样，该模型也有缺陷：

（1）并非所有应用都适合RAD。RAD模型对模块化要求比较高，如果哪一个功能不能被模块化，那么建造RAD所需要的构件就会有问题。

（2）开发人员和客户必须在很短时间内完成一系列的需求分析。任何一方配合不当都会导致RAD项目失败。

（3）RAD不适合技术风险很高的软件项目。当一个新应用要采用很多新技术，软件要求与已有的计算机程序具有高互操作性时，技术风险较高，不宜采用RAD。

9．软件包模型

软件包模型（见图2-21）主要用于开发依赖于外购（协）软件产品和重用软件包的系统。

图2-21　软件包模型

软件包模型一般遵循下述步骤：

（1）需求分析和软件包标识。在需求定义和分析期间，确定要使用的外购（协）软件包，构造原型系统以评价产品的功能和性能，并确定初步的系统结构。

（2）结构定义和软件包选择。一旦原型的结果适合使用外购（协）软件，则应确定它与系统其余部分的接口，并确定系统的最终结构。否则选择其他外购（协）软件包，重新定义结构。

（3）系统集成和测试。在实现期间，由于外购（协）软件包没有源代码，不能进行单元测试，因而直接进行系统集成和测试。

（4）技术修改和系统维护。根据用户的使用情况，对交付后的系统进行技术修改和系统维护以改进系统。

软件包模型的优点：与从头开发等价的功能相比，开发费用低、开发周期短；可以提高最终产品的质量。

软件包模型的缺点：可能会产生期望功能和外购软件提供功能之间的折中；可维护性面临更大的挑战，因为外购软件的来源可能并不是同一个开发机构（例如，外购软件制造有发布更新版本时，需要第三方更改，并造成软件配置管理问题）。

软件包模型适用情况：外购软件可以提供支持开发软件项目的大部分系统功能。

10．遗留系统维护模型

遗留系统维护模型（见图2-22），主要用于纠错性维护或者对一个运行系统稍加改进。如果需要改变软件结构，应使用瀑布模型或者增量模型。在维护期间，也可以执行某些在软件中经过选择的活动。遗留系统维护模型在本质上类似于瀑布模型，主要差别是该模型已经建立了结构设计。

图2-22　遗留系统维护模型

遗留系统维护模型的优点：定义清楚，易于建模和理解，便于计划和管理；有支持该模型的多种工具；适用于一个运行系统的纠错性维护或局部改进。

遗留系统维护模型的缺点：不适用于需要改变软件结构的适应性维护；不适用于需要改变软件结构的完善性维护；不适用于新软件的开发。

遗留系统维护模型的适用情况：包含纠错及少量改进的维护项目。

遗留系统维护模型的适用情况：

（1）产品复杂，不断有新的需求加入。

当产品的开发受市场影响较大时，业务需求的变动就十分常见了，为了不影响项目开发进度，需求管理必不可少。有些团队会一个个排需求、做需求，而敏捷开发是通过任务分解把工作拆分为半天到几天的工作量，然后制订里程碑时间点，将复杂的需求细化成一个个小任务，再根据轻重缓急梳理优先级，帮助开发人员化繁为简，提高效率。

（2）团队庞大，沟通协作效率低

有时一款新产品的开发，需要多部门联动协作，然而每个成员的岗位和职责不同，所以每个人关注的项目信息不一样，关注信息的频率其实也不一样，有的比较频繁，有的则可能整个项目过程就只需沟通两三次。由于每个人的习惯不同，所以获取信息的手段也不太一样，有些人喜欢微信、QQ，有些人喜欢邮件，还有些人喜欢以会议的形式获取信息。这就导致了团队内部沟通效率低下，许多重要的信息难以实时传递。

（3）希望高效地管理开发进度。

产品经理为了掌握项目的进展，掌握各项工作的状况，就必须对项目过程进行监控和跟踪。只有这样，出现了问题才能及时进行资源调整和进度计划调整，重新规划某一个任务开始和结束的时间，并记录实际的进度情况。

11．敏捷开发模型

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系、但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。敏捷开发模型如图2-23所示。

图2-23　敏捷开发模型

敏捷开发模型核心是快速迭代、拥抱变化。因为最终目标是让客户满意，所以能够主动接受需求变更，这就使设计出来的软件有灵活性、可扩展性。

敏捷开发模型主张：

（1）“个体和交互”胜过“过程和工具”。

（2）“可以工作的软件”胜过“面面俱到的文档”。

（3）“客户合作”胜过“合同谈判”。

（4）“响应变化”胜过“遵循计划”。

敏捷开发模式有以下显著的特点：

（1）story（可测试的小功能点）细化。

（2）简单设计，避免过度设计。

（3）重复迭代。

（4）减少不必要的文档。

（5）客户最关心的功能最先完成。

（6）要求客户有时间对每次迭代的成果进行确认，提出改进意见。

（7）沟通是非常重要的，所有的开发人员对项目活动的理解应该是一致的。加强团队之间和客户之间的沟通。

（8）测试驱动开发（TDD）。

（9）需要更强的个人和团队能力。

（10）敏捷的管理是团队的自我管理和项目经理的服务式管理。

（11）敏捷开发不能在一开始就给出项目完整的成本计划。

（12）在有技术问题还没有解决的情况下不适合展开迭代。

敏捷模型的优点：短周期开发；增量开发；由程序员和测试人员编写的自动化测试来监控开发进度；通过口头沟通、测试和源代码来交流系统的结构和意图；编写代码之前先写测试代码，也叫做测试先行。

敏捷模型的缺点：团队的组建较难，人员素质要求较高；对测试员要求完全掌握各种脚本语言编程，会单元测试。