如同任何事物都有一个发生、发展、成熟，直至衰亡的全过程一样，软件系统或软件产品 也有一个定义、开发、运行维护，直至被淘汰这样的全过程，我们把软件将要经历的这个全过 程称为软件的生命周期。 为了使软件生命周期中的各项任务能够有序地按照规程进行，需要一定的工作模型对各项 任务给以规程约束，这样的工作模型被称为软件过程模型，或软件生命周期模型。它是一个有 关项目任务的结构框架，规定了软件生命周期内各项任务的执行步骤与目标。 本章将介绍瀑布模型、原型模型、螺旋模型、喷泉模型和组件模型等过程模型。需要注意 的是，这些模型并不是有关软件开发进程的固定格式，而只是一种参考标准。实际上，不同的 软件项目需要不同的过程模型提供支持，并且还需要根据项目的具体情况，软件开发机构工作方式、管理模式等，对一些标准模型进行适当的调整与补充，以适应项目应用的需要。
一、软件生命周期
根据我国国家标准《计算机软件开发规范》（GB 8566—8），软件生命周期包含：软件定义、 软件开发、软件运行维护三个时期，并可以细分为可行性研究、项目计划、需求分析、概要设 计、详细设计、编码实现与单元测试、系统集成测试、系统确认验证、系统运行与维护等几个 阶段。应该说，这是软件生命周期的基本构架，在实际软件项目中，根据所开发软件的规模、 种类，软件开发机构的习惯做法，以及软件开发中所采用的技术方法等，可以对各阶段进行必 要的合并、分解或补充。
1.软件定义期
软件定义是软件项目的早期阶段，主要由软件系统分析人员和用户合作，针对有待开发的 软件系统进行分析、规划和规格描述，确定软件是什么，为今后的软件开发做准备。这个时期 往往需要分阶段地进行以下几项工作。
（1）软件任务立项
软件项目往往开始于任务立项，并需要以“软件任务立项报告”的形式针对项目的名称、 性质、目标、意义和规模等作出回答，以此获得对准备着手开发的软件系统的最高层描述。
（2）项目可行性分析
在软件任务立项报告被批准以后，接着需要进行项目可行性分析。 可行性分析是针对准备进行的软件项目进行的可行性风险评估。因此，需要对准备开发的 软件系统提出高层模型，并根据高层模型的特征，从技术可行性、经济可行性和操作可行性这 三个方面，以“可行性研究报告”的形式，对项目作出是否值得往下进行的回答，由此决定项 目是否继续进行下去。
(3) 制定项目计划
在确定项目可以进行以后，接着需要针对项目的开展，从人员、组织、进度、资金、设备 等多个方面进行合理的规划，并以“项目开发计划书”的形式提交书面报告。
(4) 软件需求分析
软件需求分析是软件规格描述的具体化与细节化，是软件定义时期需要达到的目标。 需求分析要求以用户需求为基本依据，从功能、性能、数据、操作等多个方面，对软件系 统给出完整、准确、具体的描述，用于确定软件规格。其结果将以“软件需求规格说明书”的 形式提交。 在软件项目进行过程中，需求分析是从软件定义到软件开发的最关键步骤，其结论不仅是今后软件开发的基本依据，同时也是今后用户对软件产品进行验收的基本依据。
2.软件开发期
在对软件规格完成定义以后，接着可以按照“软件需求规格说明书”的要求对软件实施开 发，并由此制作出软件产品。这个时期需要分阶段地完成以下几项工作。
（1）软件概要设计
概要设计是针对软件系统的结构设计，用于从总体上对软件的构造、接口、全局数据结构 和数据环境等给出设计说明，并以“概要设计说明书”的形式提交书面报告，其结果将成为详细设计与系统集成的基本依据。 模块是概要设计时构造软件的基本元素，因此，概要设计中软件也就主要体现在模块的构 成与模块接口这两个方面上。结构化设计中的函数、过程，面向对象设计中的类、对象，它们都 是模块。概要设计时并不需要说明模块的内部细节，但是需要进行全部的有关它们构造的定义， 包括功能特征、数据特征和接口等。 在进行概要设计时，模块的独立性是一个有关质量的重要技术性指标，可以使用模块的内 聚、耦合这两个定性参数对模块独立性进行度量。
（2）软件详细设计
设计工作的第二步是详细设计，它以概要设计为依据，用于确定软件结构中每个模块的内 部细节，为编写程序提供最直接的依据。 详细设计需要从实现每个模块功能的程序算法和模块内部的局部数据结构等细节内容上 给出设计说明，并以“详细设计说明书”的形式提交书面报告。
（3）编码和单元测试
编码是对软件的实现，一般由程序员完成，并以获得源程序基本模块为目标。 编码必须按照“详细设计说明书”的要求逐个模块地实现。在基于软件工程的软件开发过 程中，编码往往只是一项语言转译工作，即把详细设计中的算法描述语言转译成某种适当的高 级程序设计语言或汇编语言。 为了方便程序调试，针对基本模块的单元测试也往往和编码结合在一起进行。单元测试也以 “详细设计说明书”为依据，用于检验每个基本模块在功能、算法与数据结构上是否符合设计要求。
（4）系统集成测试
所谓系统集成也就是根据概要设计中的软件结构，把经过测试的模块，按照某种选定的集成策略，例如渐增集成策略，将系统组装起来。 在组装过程中，需要对整个系统进行集成测试，以确保系统在技术上符合设计要求，在应用上满足需求规格要求。
（5）系统确认验证
在完成对系统的集成之后，接着还要对系统进行确认验证。 系统确认验证需要以用户为主体，以需求规格说明书中对软件的定义为依据，由此对软件 的各项规格进行逐项地确认，以确保已经完成的软件系统与需求规格的一致性。为了方便用户 在系统确认期间能够积极参入，也为了系统在以后的运行过程中能够被用户正确使用，这个时期往往还需要以一定的方式对用户进行必要的培训。 在完成对软件的验收之后，软件系统可以交付用户使用，并需要以“项目开发总结报告” 的书面形式对项目进行总结。
3.软件运行与维护期
软件系统的运行是一个比较长久的过程，跟软件开发机构有关的主要任务是对系统进行经常性的有效维护。 软件的维护过程，也就是修正软件错误，完善软件功能，由此使软件不断进化升级的过程， 以使系统更加持久地满足用户的需要。因此，对软件的维护也可以看成为对软件的再一次开发。 在这个时期，对软件的维护主要涉及三个方面的任务，即改正性维护、适应性维护和完善性维护。
二、瀑布模型
瀑布模型诞生于 20 世纪 70 年代，是最经典的并获得最广泛应用的软件过程模型。图 2-1 是传统瀑布模型的图样表示。
瀑布模型中的“瀑布”是对这个模型的形象表达，即山顶倾泻下来的水，自顶向下、逐层 细化。其中，自顶向下中的顶，可以理解为软件项目初期对软件问题的模糊认识，需要经过需求分析，才能使软件问题逐步清晰，而获得对软件规格的明确定义，由此使软件项目由定义期 过渡到开发期，并经过软件开发而最终得到需要实现的软件产品这个最底层结果。瀑布模型中 的逐层细化，其含义则是对软件问题的不断分解而使问题不断具体化、细节化，以方便问题的解决。
1. 瀑布模型的特点
（1）线性化模型结构
瀑布模型所考虑的软件项目是一种稳定的线性过程。项目被划分为从上至下按顺序进行的 几个阶段，阶段之间有固定的衔接次序，并且前一阶段输出的成果被作为后一阶段的输入条件。
（2）各阶段具有里程碑特征
瀑布模型中的阶段只能逐级到达，不能跨越。每个阶段都有明确的任务，都需要产生出确 定的成果。
（3）基于文档的驱动
文档在瀑布模型中是每个阶段的成果体现，因此，文档也就成为了各个阶段的里程碑标志。 由于后一阶段工作的开展是建立在前一阶段所产生的文档基础之上，因此，文档也就成为了推动下一阶段工作开展的前提动力。
（4）严格的阶段评审机制
在某个阶段的工作任务已经完成，并准备进入到下一个阶段之前，需要针对这个阶段的文 档进行严格的评审，直到确认以后才能启动下一阶段的工作。
2. 瀑布模型的作用
瀑布模型是一种基于里程碑的阶段过程模型，它所提供的里程碑式的工作流程，为软件项目按规程管理提供了便利，例如，按阶段制定项目计划，分阶段进行成本核算，进行阶段性评审等；并对提高软件产品质量提供了有效保证。 瀑布模型的作用还体现在文档上。每个阶段都必须完成规定的文档，并在每个阶段结束前 都要对所完成的文档进行评审。这种工作方式有利于软件错误的尽早发现和尽早解决，并为软件系统今后的维护带来了很大的便利。 应该说，瀑布模型作为经典的软件过程模型，为其他过程模型的推出提供了一个良好的拓 展平台。
3. 带有信息反馈环的瀑布模型
在实际的软件项目中存在着许多不稳定因素。例如，开发中的工作疏漏或通信误解；在项目实施中途，用户可能会提出一些新的要求；开发者也可能在设计中遇到某些未曾预料的实际困难，希望在需求中有所权衡等。 考虑到许多实际项目中阶段之间有通信的需要，也就有了一种经过改进的，跟实际开发环 境更加接近的瀑布模型，如图 2-2 所示。改进后的瀑布模型带有信息反馈环，能够逐级地将后续阶段的意见返回，并在问题解决之后，再逐级地将修正结果下传。
需要注意的是，为了确保文档内容的一致性，信息反馈过程中任何有关影响文档变更的行 为，只能在相邻阶段之间逐级地进行。
4. 瀑布模型的局限
瀑布模型是一种线性模型，要求项目严格按规程推进，必须等到所有开发工作全部作完以 后才能获得可以交付的软件产品。应该讲，通过瀑布模型并不能对软件系统进行快速创建，对 于一些急于交付的软件系统的开发，瀑布模型有操作上的不便。 瀑布模型主要适合于需求明确，且无大的需求变更的软件开发，例如，编译系统、操作系统等。但是，对于那些分析初期需求模糊的项目，例如那些需要用户共同参加需求定义的项目， 瀑布模型也有使用上的不便。
三、原型模型
1.快速原型的方法
快速原型方法是原型模型在软件分析、设计阶段的应用，用来解决用户对软件系统在需求 上的模糊认识，或用来试探某种设计是否能够获得预期结果。 快速原型方法具有以下一些特点：
（1）快速原型是用来获取用户需求的，或是用来试探设计是否有效的。一旦需求或设计确 定下来了，原型就将被抛弃。因此，快速原型要求快速构建、容易修改，以节约原型创建成本、 加快开发速度。快速原型往往采用一些快速生成工具创建，例如 4GL 语言。目前，Microsoft Visual Basic、Inprise Delphi 等基于组件的可视化开发工具，也被应用于原型创建之中，并 且都是非常有效的快速原型创建工具，而且还可用于原型进化。
（2）快速原型是暂时使用的，因此并不要求完整。它往往针对某个局部问题建立专门原型， 如界面原型、工作流原型、查询原型等。 （3）快速原型不能贯穿软件的整个生命周期，它需要和其他的过程模型相结合才能产生作 用。例如，在瀑布模型中应用快速原型，以解决瀑布模型在需求分析时期存在的不足。
2. 原型进化模型
原型进化对开发过程的考虑是，针对有待开发的软件系统，先开发一个原型系统给用户使用，然后根据用户使用情况的意见反馈，对原型系统不断修改，使它逐步接近并最终到达开发目标。跟快速原型不同的是，快速原型在完成需求定义后将被抛弃，而原型进化所要创建的原型则是一个今后将要投入应用的系统，只是所创建的原型系统在功能、性能等方面还有许多不 足，还没有达到最终开发目标，需要不断改进。 原型进化的工作流程如图 2-3 所示。从图中可以看到，它具有以下两个特点：
（1）原型进化模型将软件的需求细部定义、产品开发和有效性验证放在同一个工作进程中 交替或并行运作。因此，在获得了软件需求框架以后，例如软件的基本功能被确定以后，就可以直接进入到对软件的开发中。
（2）原型进化模型是通过不断发布新的软件版本而使软件逐步完善的，因此，这种开发模式特别适合于那些用户急需的软件产品开发。它能够快速地向用户交付可以投入实际运行的软件成果，并能够很好地适应软件用户对需求规格的变更。 原型进化模型能够适应软件需求的中途变更，但在应用的时候，以下问题需要得到足够的 重视。
其一，原型进化模型虽说使开发进程加快了，但不能像瀑布模型那样提供明确的里程碑管 理，随着开发过程中版本的快速更新，项目管理、软件配置管理会变得复杂起来，管理者难以把握开发进度。因此，对于大型软件项目，原型进化模型缺乏有效的管理规程。
其二，开发过程中软件版本的快速变更，还可能损伤软件的内部结构，使其缺乏整体性和稳定性。另外，用于反映软件版本变更的文档也有可能跟不上软件的变更速度。这些问题必将影响到今后软件的维护。
3.增量模型
瀑布模型较难适应用户的需求变更，开发速度慢。但是，瀑布模型提供了一套工程化的里程碑管理模式，能够有效保证软件质量，并使得软件容易维护。 相反地，原型进化模型则可以使对软件需求的详细定义延迟到软件实现时进行，并能够使软件开发进程加速。但是，原型进化模型不便于工业化流程管理，也不利于软件结构的优化， 并可能使得软件难以理解和维护。 基于以上因素的考虑，增量模型对这两种模型的优点进行了结合。
1.增量模型的优点
增量模型是瀑布模型和原型进化模型的综合，它对软件过程的考虑是：在整体上按照瀑布模型的流程实施项目开发，以方便对项目的管理；但在软件的实际创建中，则将软件系统按功能分解为许多增量构件，并以构件为单位逐个地创建与交付，直到全部增量构件创建完毕，并都被集成到系统之中交付用户使用。 如同原型进化模型一样，增量模型逐步地向用户交付软件产品，但不同于原型进化模型的是，增量模型在开发过程中所交付的不是完整的新版软件，而只是新增加的构件。 图 2-4 是增量模型的工作流程，它被分成以下三个阶段：
（1）在系统开发的前期阶段，为了确保所建系统具有优良的结构，仍需要针对整个系统进行需求分析和概要设计，需要确定系统的基于增量构件的需求框架，并以需求框架中构件的组成及关系为依据，完成对软件系统的体系结构设计。
（2）在完成软件体系结构设计之后，可以进行增量构件的开发。这个时候，需要对构件进行需求细化，然后进行设计、编码测试和有效性验证。
（3）在完成了对某个增量构件的开发之后，需要将该构件集成到系统中去，并对已经发生 了改变的系统重新进行有效性验证，然后再继续下一个增量构件的开发。
2.增量模型的作用
增量模型带来了以下几方面的作用。
（1）开发初期的需求定义只是用来确定软件的基本结构，这使得开发初期，用户只需要对 软件需求进行大概的描述，而对于需求的细节性描述，则可以延迟到增量构件开发时进行，以增量构件为单位逐个地进行需求补充。这种方式有利于用户需求的逐渐明朗，能够有效适应用户需求的变更。
（2）软件系统可以按照增量构件的功能安排开发的优先顺序，并逐个实现和交付使用。这不仅有利于用户尽早地用上系统，能够更好地适应新的软件环境，而且用户在以增量方式使用 系统的过程中，还能够获得对软件系统后续构件的需求经验。这样能使软件需求定义越往后越 顺利。
（3）软件系统是逐渐扩展的，因此，开发者可以通过对诸多构件的开发，逐步积累开发经验。实际上，增量式开发还有利于技术复用，前面构件中设计的算法、采用的技术策略、编写的源码等，都可以应用到后面将要创建的增量构件中去。
（4）增量式开发还有利于从总体上降低软件项目的技术风险。个别的构件或许不能使用， 但这一般不会影响到整个系统的正常工作。 （5）实际上，在采用增量模型时，具有最高优先权的核心增量构件将会被最先交付，而随着后续构件不断被集成进系统，这个核心构件将会受到最多次数的测试。这意味着软件系统最 重要的心脏部分将具有最高的可靠性，这将使得整个软件系统更具健壮性。 可以说，比较瀑布模型、原型进化模型，增量模型具有非常显著的优越性。但是，增量模型对软件设计有更高的技术要求，特别是对软件体系结构，要求它具有很好的开放性与稳定性， 能够顺利地实现构件的集成。在把每个新的构件集成到已建软件系统的结构中的时候，一般要求这个新增的构件应该尽量少地改变原来已建的软件结构。因此增量构件要求具有相当好的功能独立性，其接口应该简单，以方便集成时与系统的连接。
4.螺 旋 模 型
软件开发过程中存在许多方面的风险。例如，软件设计时遇到了很难克服的技术难题，软件开发成本超出了先期预算，软件产品不能按期交付，用户对所交付的软件不满意等。应该说， 软件风险是任何软件项目中都普遍存在的实际问题，而且项目越大，软件越复杂，风险也就越大。由于软件风险可能在不同程度上损害软件开发过程，并由此影响软件产品质量，因此，在软件开发过程中需要及时地识别风险、有效地分析风险，并能够采取适当措施消除或减少风险的危害。
螺旋模型即是一种引入了风险分析与规避机制的过程模型，是瀑布模型、快速原型方法和 风险分析方法的有机结合。 螺旋模型基本方法是，在各个阶段创建原型进行项目试验，以降低各个阶段可能遇到的项 目风险。例如，为了降低用户对软件界面不满意的风险，可以在需求分析阶段建立“界面原型”； 为了降低软件不能按设计要求实现的风险，可以在设计阶段针对所采用的技术建立“仿真试探 原型”。 图 2-5 是螺旋模型的工作流程图。它用螺旋线表示软件项目的进行情况，其中，螺旋线中 的每个回路表示软件过程的一个阶段。因此，最里面的回路与项目可行性有关，接下来的一个 回路与软件需求定义有关，而再下一个回路则与软件系统设计有关，以此类推。
螺旋线中的每个回路都被分成为四个部分：
（1）目标设置：确定项目的阶段性目标，分析项目风险。
（2）风险评估：对风险进行详细地评估分析，并确定适当的风险规避措施。
（3）开发软件：根据对风险的认识，决定采用合适的软件开发模型，实施软件开发。
（4）制定计划：对项目进行阶段评审，制定项目下一个阶段的工作计划。 对软件项目进行风险分析也是需要费用的，假如项目风险分析费用过高，甚至超过项目开发费用，显然这就不合算了。实际上，只有较大型的项目才有较高的风险，才有进行各个阶段 详细风险分析的必要。因此，螺旋模型主要应用于大型软件项目之中。
5.喷泉模型
喷泉模型是专门针对面向对象软件开发方法而提出的。“喷泉”一词用于形象地表达面向对象软件开发过程中的迭代和无缝过渡。 在面向对象方法中，对象既是对现实问题中实体的抽象，也是构造软件系统的基本元素。 因此，建立对象模型在面向对象方法中，既可以用于分析，也可以用于设计，而且分析阶段所获得的对象框架模型可以无缝过渡到设计阶段，以作为软件实现的依据。 喷泉模型的过程方法所考虑的是，基于面向对象方法所带来的便利，对软件的分析、设计 和实现按照迭代的方式交替进行，并通过进化的方式，使软件分阶段逐渐完整、逐步求精。
例 如，
第一阶段软件开发的目标可以是软件的基本功能；
第二阶段可以是在第一阶段建立的软件 的基础上，对软件进行进一步的完善，并实现软件的主要功能；
第三阶段则是在第二阶段的基 础上，对软件进行更加完整的开发，并以实现软件全部功能作为创建目标。 应该说，喷泉模型能够较有效地平衡软件系统的近期需求与远期规划，因此能够较好地满 足用户在软件应用上的发展需要。
6. 组件复用模型
自有软件开发以来，软件复用就一直存在，并产生了一些比较常用的软件复用方法。传统的软件复用方法是建立源程序函数库，可以把这些函数用在许多不同的软件上面。而在面向对象技术中，软件复用则可以通过建立类模块来实现。由于大多数的类模块具有继承性，因此， 比起传统方法，基于类模块的复用效果要好一些。 组件复用方法是最近几年才发展起来的更加先进的软件复用技术，它能带来更好的复用效果，并且更具有工程特性，更能适应软件按工业流程生产的需求。 组件技术是基于面向对象技术发展起来的，可以把组件看作为 一个盒子，它里面封装了许多个类模块。因此，组件比类更大、更 抽象，其中包含了更多的功能，更具有通用性，更加有利于复用。 在基于组件复用的软件开发中，软件由组件装配而成，这就如 同用标准零件装配汽车一样。图 2-6 是组件复用模型的工作流程， 它以组件复用为驱动。 组件复用模型主要包含以下几个阶段的工作任务。
（1）需求框架描述：描述软件系统功能构成，并将各项功能以设定的组件为单位进行区域划分。
（2）组件复用分析：按照需求框架中的组件成分，分析哪些组件是现成的，哪些组件可以在专业组件开发机构购买到，哪些组件不得不自己开发。
（3）需求修改与细化：以提高对现有组件的复用和降低新组件开发为目标，调整需求框架，并对已经确定的需求框架进行细化，由此获得对软件系统的详细需求定义。
（4）系统设计：基于组件技术设计系统框架，设计需要开发的新组件。
（5）组件开发：开发不能获得复用的新组件。
（6）系统集成：根据设计说明要求，将系统所需要的诸多组件整合在一起，构成一个完整的系统。 应该说，组件复用技术给软件开发带来了很多好处。它可以缩短开发周期、降低开发成本、 提高软件质量、方便软件维护，特别是可以使软件生产按工业流程进行。 但值得注意的是，在组件复用中有可能会遇到组件复用率与用户特殊需求之间的矛盾。例 如，开发机构希望使用现有的组件开发软件以降低开发成本，但现有组件却可能不能满足用户 的特殊需求。 另外，当采用组件复用技术实施软件开发时，软件中需要用到的组件往往是由一些专门的 软件机构提供。也就是说，基于组件的软件开发对外有很大的依赖性，显然这不太利于软件的 升级、改版。
小 结
1．软件生命周期
如同任何事物都有一个发生、发展、成熟直至衰亡的全过程一样，软件系统或软件产品也 有一个定义、开发、运行维护直至被淘汰这样的全过程，我们把软件将要经历的这个全过程称为软件的生命周期。它包含：软件定义、软件开发、软件运行维护三个时期，并可以细分为可行性研究、项目计划、需求分析、概要设计、详细设计、编码实现与单元测试、系统集成测试、 系统确认验证、系统运行与维护等几个阶段。
2．瀑布模型
瀑布模型诞生于 20 世纪 70 年代，是最经典的并获得最广泛应用的软件过程模型。瀑布模 型中的“瀑布”是对这个模型的形象表达，即山顶倾泻下来的水，自顶向下、逐层细化。
（1）特点：线性化模型、阶段具有里程碑特征、基于文档的驱动、阶段评审机制。
（2）作用：为软件项目按规程管理提供了便利，为其他过程模型的推出提供了一个良好的拓展平台。
（3）局限性：主要适合于需求明确且无大的需求变更的软件开发，但不适合分析初期需求模糊的项目。
3．原型模型
（1）快速原型方法：是原型模型在软件分析、设计阶段的应用，用来解决用户对软件系统 在需求上的模糊认识，或用来试探某种设计是否能够获得预期结果。
（2）原型进化模型：针对有待开发的软件系统，先开发一个原型给用户使用，然后根据用 户的使用意见，对原型不断修改，使它逐步接近，并最终到达开发目标。
4．增量模型
增量模型结合了瀑布模型与原型进化模型的优点。在整体上按照瀑布模型的流程实施开 发，以方便对项目的管理。但在软件的实际创建中，则将软件系统按功能分解为许多增量构件逐个地创建与交付，直到全部构件创建完毕，并都被集成到系统之中交付使用。 比较瀑布模型、原型进化模型，增量模型具有非常显著的优越性。但增量模型对软件设计有更高的技术要求。
5．螺旋模型
螺旋模型是一种引入了风险分析与规避机制的过程模型，是瀑布模型、快速原型方法和风险分析方法的有机结合。其基本方法是，在各个阶段创建原型进行项目试验，以降低各个阶段可能遇到的项目风险。
6．喷泉模型
喷泉模型是专门针对面向对象软件开发方法而提出的。“喷泉”一词用于形象地表达面向 对象软件开发过程中的迭代和无缝过渡。
7．组件复用模型
组件复用方法是最近几年发展起来的先进的软件复用技术，在基于组件复用的软件开发 中，软件由组件装配而成，这就如同用标准零件装配汽车一样。因此，组件复用模型能够有效 地提高软件生产率。
