2.4 软件过程模型
软件过程是整个软件生命周期中一系列有序的软件生产活动的流程。为了能高效地开发一个高质量的软件产品，通常把软件生命周期中各项开发活动的流程用一个合理的框架——开发模型来规范描述，这就是软件过程模型，或者称为软件生命周期模型。所以，软件过程模型是一种软件过程的抽象表示法，“建模”是软件过程中最常使用的技术手段之一。
软件过程模型是从一个特定的角度表现一个过程，一般使用直观的图形标识软件开发的过程，主要根据软件的类型、规模，特别是软件的开发方法、开发环境等多种因素确立过程模型。
过程定义了运用方法的顺序、应该交付的文档资料、为保证软件质量和协调变化所需要采取的管理措施，以及标志软件开发各个阶段任务完成的里程碑。通常使用生命周期模型简洁地描述软件过程。生命周期模型规定了把生命周期划分成哪些阶段及各个阶段的执行顺序，因此，也称为过程模型。
几十年来，软件工程领域先后出现了多种不同的软件过程模型，典型的代表是瀑布模型、螺旋模型、演化式模型和面向对象模型。它们各具特色，分别适用于不同特征的软件项目的开发应用。
2.4.1 传统软件过程模型
1．瀑布模型
在20世纪80年代之前，瀑布模型是最早也是应用最广泛的软件过程模型，现在它仍然是软件工程中应用最广泛的过程模型。瀑布模型提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容，给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。
各个阶段产生的文档是维护软件产品时必不可少的，没有文档的软件几乎是不可能维护的。瀑布模型中的文档约束，使软件维护变得更加容易。由于绝大部分软件预算都花费在软件维护上，因此，使软件变得比较容易维护就能显著降低软件预算。可以说，瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型。但是，瀑布模型是由文档驱动，也是其一个主要缺点。软件产品交付给用户之前，用户只能通过文档来了解产品是什么样的。但仅仅通过写在纸上的规格说明，用户很难全面正确地认识动态的软件产品。
瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。从本质来讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好“返回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一个阶段，这也是瀑布开发名称的由来。采用瀑布模型的软件过程如图2-1所示。
按照传统的瀑布模型开发软件，有下述的几个特点。
1）阶段的顺序性和依赖性：瀑布模型的各个阶段之间存在着这样的关系——后一阶段的工作必须等前一阶段的工作完成之后才能开始。同时，前一阶段的输出文档就是后一阶段的输入文档，因此，只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果。
2）推迟实现的观点：对于规模较大的软件项目来说，往往编码开始得越早最终完成开发工作所需要的时间越长。主要原因是前面阶段的工作没做或做得不到位，过早地进行下一阶段的工作，往往导致大量返工，有时甚至产生无法弥补的问题，带来灾难性后果。瀑布模型在编码之前设置了系统分析与系统设计的各个阶段。分析与设计阶段的基本任务规定，在这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的编程实现。清楚地区分逻辑设计与物理设计，尽可能推迟程序的编程实现，是按照瀑布模型开发软件的一条重要的指导思想。
3）质量保证的观点：软件开发最基本的目标是开发效率高，产品质量高。为保证软件的质量，首先，在瀑布模型的每个阶段都必须完成规定的文档，只有交出合格的文档才算是完成该阶段的任务。完整、准确的合格文档不仅是软件开发时期各类人员之间相互沟通的媒介，也是运行时期对软件进行维护的重要依据。其次，在每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。事实上，越是早期阶段犯下的错误，暴露出来的时间就越晚，排除故障改正错误所需付出的代价也越高。
4）文档驱动的观点：瀑布模型着重强调文档的作用，并要求每个阶段都要仔细验证。但这种模型的线性过程太理想化，已不再适合现代化软件开发的模式，其主要问题在于：各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；客户要等到开发周期的晚期才能看到程序运行的测试版本，而在这时发现大的错误，可能引起客户的惊慌，后果也可能是灾难性的；实际的项目大部分情况难以按照该模型给出的顺序进行，而且这种模型的迭代是间接的，这很容易由微小的变化造成大的混乱；采用这种线性模型，会经常在过程的开始和结束时碰到等待其他成员完成其所依赖的任务才能进行下去的情况，有可能花在等待上的时间比开发的时间要长。
2．增量模型
增量模型（Incremental Model）是在项目的开发过程中以一系列的增量方式开发系统。在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。
增量方式包括增量开发和增量提交。增量开发是指在项目开发周期内，以一定的时间间隔开发部分工作软件；增量提交是指在项目开发周期内，以一定的时间间隔增量方式向用户提交工作软件及相应文档。根据增量的方式和形式的不同，分为渐增模型和原型模型。
渐增模型是瀑布模型的变种，有两类渐增模型：
- 总体开发增量构造模型：它在瀑布模型的基础上，对一些阶段进行整体开发，对另一些阶段进行增量开发。前面的开发阶段按瀑布模型进行整体开发，后面的开发阶段按增量方式开发。增量构造模型如图2-2所示。在增量构造模型中，需求分析阶段和设计阶段都是按瀑布模型的整体方式开发，但是编码阶段和测试阶段是按增量方式开发。
- 增量开发增量提交模型：它在瀑布模型的基础上，所有阶段都进行增量开发，也就是说不仅是增量开发，也是增量提交。在增量提交模型中，项目开发的各个阶段都是增量方式。先对某部分功能进行需求分析，然后顺序进行设计、编码、测试，把该功能的软件交付给用户，然后再对另一部分功能进行开发，提交用户直至所有功能全部增量开发完毕。
增量构造和增量提交的一些区别：增量构造是在瀑布模型的基础上，一些阶段采用增量开发，另一些阶段采用整体开发。增量提交是在瀑布模型的基础上，所有阶段不仅采用增量开发也采用增量提交。
增量构造模型与原型模型和其他演化方法一样，本质上都是迭代的，但与原型模型不一样的是，它强调每一个增量都发布一个可操作的产品。早期的增量是最终产品的“可拆卸”版本，但提供了为用户服务的功能，并且为用户提供了评估的平台。
增量模型融合了线性顺序模型的基本成分和原型模型的迭代特征。增量模型采用随着日程时间的进展而交错的线性序列。每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时，第一个增量往往是核心的产品，也就是说第一个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估，都作为下一个增量发布的新特征和功能。这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。
增量模型引进了增量包的概念，无须等到所有需求都出来，只要某个需求的增量包出来即可进行开发。虽然某个增量包可能需要进一步适应客户的需求并且更改，但只要这个增量包足够小，其影响对整个项目来说是可以承受的。
增量模型的人员分配灵活，刚开始不用投入大量人力资源；如果核心产品很受欢迎，则可增加人力实现下一个增量；当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径。这样即可先发布部分功能给客户，以便稳定客户。此外，增量能够有计划地管理技术风险。
增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的可运行产品的一个子集。整个产品被分解成若干个构件，开发人员逐个交付产品，这样软件开发可以很好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。但是，增量模型也存在以下缺陷：
1）各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
2）在实际的软件开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。
3）如果增量包之间存在相交的情况且未很好的处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适用于需求经常改变的软件开发过程。
3．螺旋模型
螺旋模型（Spiral Model）是在1988年，由Barry Boehm正式提出的模型，它将瀑布模型和快速原型模型结合起来，它不仅体现了两个模型的优点，而且还强调了其他模型均忽略了风险分析，特别适合于大型复杂的系统。这种模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段，由这4个阶段进行迭代。软件开发过程每迭代一次，软件开发就前进一个层次。采用螺旋模型的软件过程如图2-3所示。
在“瀑布模型”的每一个开发阶段前引入非常严格的风险识别、风险分析和风险控制，它把软件项目分解成一个个小项目。每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。该模型沿着螺旋线进行若干次迭代，图中的四个象限分别代表了以下活动：
1）制定计划：确定软件目标，选定实施方案，确定项目开发的限制条件。
2）风险分析：分析评估所选方案，考虑如何识别和消除风险。
3）实施工程：实施软件开发和验证。
4）客户评估：评价开发工作，提出修正建议，制定下一步计划。
螺旋模型有许多优点：对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标；减少了过多测试或测试不足所带来的风险；更重要的是，在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别。与瀑布模型相比，螺旋模型支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供了方便，有助于提高目标软件的适应能力。并且为项目管理人员及时调整管理决策提供了便利，从而降低了软件开发风险。
螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，帮助我们将软件质量作为特殊目标融入产品开发之中。但螺旋模型也有一定的限制条件：螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应，因此特别适用于复杂并具有高风险的系统。对于这些系统，风险是软件开发不可忽视且潜在的不利因素，它可能在不同程度上损害软件开发过程，影响软件产品的质量。减小软件风险的目标是在造成危害之前，及时对风险进行识别及分析，决定采取何种对策，进而消除或减少风险的损害。
如果执行风险分析将大大影响项目的利润，则风险分析是不可行的，那么进行风险分析就显得毫无意义，因此，螺旋模型只适合于大规模软件项目。事实上，项目越大，风险也越大，因此，进行风险分析的必要性也越大。此外，只有内部开发的项目，才能在风险过大时中止项目。螺旋模型的主要优势在于，它是风险驱动的，但是，这也可能是它的一个劣势。软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险。
2.4.2 面向对象过程模型
从方法学的角度可以认为，面向对象的方法是面向对象的世界观在开发方法中的直接运用。它强调系统的结构应该直接与现实世界的结构相对应，应该围绕现实世界中的对象来构造系统，而不是围绕功能来构造系统。
正确地运用面向对象方法学开发软件，则最终的软件产品由许多较小的、基本上独立的对象组成，每个对象相当于一个小型的程序，而且大多数对象都与现实世界中的实体相对应，这样就降低了软件产品的复杂性，提高了软件的可理解性，简化了软件的开发和维护工作。对象是相对独立的实体，可以在以后的软件产品中复用。基于此，面向对象范型的另一个重要优点是促进了软件复用。面向对象方法特有的继承性和多态性，进一步提高了面向对象软件的可重用性。
1．统一过程模型
统一过程（Unified Process，UP）是风险驱动的、基于用例技术的、以架构为中心的、迭代的、可配置的软件开发流程。UP是一个面向对象且基于网络的程序开发方法论。根据Rational Rose和统一建模语言的开发者的说法，它可以为所有方面和层次的程序开发提供指导方针、模板以及事例支持。
统一过程是一个软件开发过程，是一个通用的过程框架，可以用于各类软件系统和应用领域。统一过程是以用例驱动的，以架构为中心，迭代和增量的过程。统一过程是在重复一系列组成系统生命周期的循环。每一次循环包括4个阶段：初始、细化、构造和移交。每个阶段又进一步细分为多次迭代的过程，如图2-4所示。
每次循环迭代会产生一个新的版本，每个版本都是一个准备交付的产品。
1）初始阶段。在初始阶段形成将好的想法发展为最终产品的构想，提出了该产品的业务实例。该阶段要完成：系统向它的每个重要用户提供的基本功能是什么？该系统的逻辑架构大概是什么样子？开发该产品的计划如何？开销多大？在该阶段主要建立关键用例的简化用例模型，用于刻画系统主要功能。架构是实验性的，通常是包括主要子系统的大致的轮廓。要确定最主要的风险及其优先次序，要对细化阶段进行详细规划，并对项目进行粗略估算。
2）细化阶段。在细化阶段，详细说明该系统的绝大多数用例，并设计出系统的架构。架构可以表示为系统中所有模型的不同视图，合起来表示整个系统，即架构包括用例模型、分析模型、设计模型、实现模型和实施模型的视图。在细化阶段末期，要规划完成项目的活动，估算完成项目所需的资源。关键问题是用例、架构和计划是否足够稳定、可靠，风险是否得到控制，以便按照合同的规定完成整个开发任务。该阶段的结果是架构基线。
3）构造阶段。构造阶段将构造出最终产品——软件。在该阶段架构基线逐步发展成为完善的系统，将消除所需要的大部分资源，架构可以进行微调，但系统架构是稳定可靠的。要回答的问题是早期交付给客户的产品是否完全满足客户的需求。
4）移交阶段。移交阶段包括产品进入分析后期的整个阶段，用户使用分析法发现产品的缺陷和不足，开发人员改正问题及完善系统形成更通用的版本。该阶段包括制作、用户培训、提供在线支持以及改正交付之后发现的缺陷活动。
统一过程在定义4个阶段及其迭代过程时，又给出了5个核心工作流：需求、分析、设计、实现和测试。每个工作流在各个阶段所处的地位和工作是不同的。图2-5给出了统一过程的核心工作流。
1）需求工作流。需求工作流的目的是致力于开发正确的系统。需求工作流就是要足够详细地描述系统需求，使客户和开发人员在系统应该做什么和不应该做什么方面达成共识。
2）分析工作流。分析工作流的目的是更精确地理解需求，也是为了得到一个易于维护且有助于确定系统结构的需求描述。与需求工作流相比，分析工作流可以采用开发人员熟悉的语言来描述和组织需求。分析工作流的任务是探究系统内部，解决用例间的干扰以及类似的问题。分析得到的需求结构可用作构造整个系统的基本输入。分析工作流使用分析模型表达系统的本质。
3）设计工作流。设计工作流的目的是深入理解与非功能性需求和约束相联系的编程语言、构件使用、操作系统、分布与并发技术、数据库技术、用户界面技术和事务管理技术等相关问题。设计工作流要把实现工作划分成更易于管理的各个部分，捕获早期子系统之间的主要接口，建立对系统实行的无缝抽象。
4）实现工作流。实现工作流探讨如何用源代码、脚本、二进制代码、可执行体等构件来实现系统。实现工作流的目的是规划每次迭代中所要求的系统集成，通过把可执行构件映射到实施模型中的节点的方式来分布系统，实现设计过程中发现的设计类和子系统，对构件进行单元测试。
5）测试工作流。测试工作流通过测试每一个增量来验证实现的结构。测试工作流的目的是为了规划每一次迭代需要的测试工作，包括集成测试和系统测试。测试工作流的任务是设计和实现测试，执行各种测试并系统地处理每个测试的结果。
统一过程描述了如何为软件开发团队有效地部署经过商业化验证的软件开发方法。它的目标是在可预见的日程和预算前提下，确保开发出满足最终用户需求的高质量产品。为使整个团队有效利用最佳实践，统一过程为每个团队成员提供了必要准则、模板和工具指导。
1）迭代软件开发。针对复杂的软件系统，RUP使用连续的开发方法，并支持专注于处理生命周期中每个阶段中最高风险的迭代开发方法，极大地减少了项目的风险性。迭代方法通过可验证的方法来帮助减少风险——增量提交的可执行版本使最终用户不断地介入和反馈。
2）需求管理。统一过程描述了如何提取、组织和文档化需要的功能与限制。它们给开发和发布系统提供了连续的和可跟踪的线索。捕获功能性需求使用了用例和场景，并确保由它们来驱动设计、实现和软件的测试，使开发出的软件更加满足最终用户的需要。
3）基于构件的体系结构。统一过程支持基于构件的软件开发。构件是实现清晰功能的模块、子系统。在开发之前，关注早期的开发和健壮可执行体系结构的基线。它描述了如何设计灵活的、可容纳修改的、直观便于理解的，并且促进有效软件重用的弹性结构。
4）可视化软件建模。开发过程注重可视化建模，捕获体系结构和构件的构架与行为。这样，我们就可以隐藏细节和使用“图形构件块”来书写代码。可视化抽象能帮助我们沟通软件的不同方面，观察各元素如何配合在一起，确保构件模块与代码一致，保持设计和实现的一致性，促进明确的沟通。Rational软件公司创建的工业级标准统一建模语言（Unified Modeling Language，UML)是成功可视化软件建模的基础。
5）验证软件质量。质量应该基于可靠性、功能性、应用和系统性能，根据需求来进行验证。UP帮助计划、设计、实现、执行和评估这些测试类型。
6）控制软件变更。开发过程描述了如何控制、跟踪和监控修改以确保成功的迭代开发。它同时指导如何通过隔离修改和控制整个软件产物的修改来为每个开发者建立安全的工作区。
统一过程主要的优点：提高了团队生产力，在迭代的开发过程、需求管理、基于构件的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面，针对所有关键的开发活动为每个开发成员提供了必要的准则、模板和工具指导，并确保全体成员共享相同的知识基础。统一过程也存在一些缺点：统一过程只是一个开发过程，并没有涵盖软件过程的全部内容，如它在软件运行和支持等方面的内容略有不足；此外，它没有支持多项目的开发结构，这在一定程度上降低了在开发组织内大范围实现重用的可能性。统一过程是一个非常好的开端，但并不完美，在实际的应用中可以根据需要对其进行改进并可以用其他软件过程的相关模型对统一过程进行补充和完善。
2．构件集成模型
构件集成模型利用模块化方法将整个系统模块化，并在一定构件模型的支持下复用构件库中的软件构件，通过组合手段提高应用软件系统过程的效率和质量。构件集成模型融合了螺旋模型的许多特征，本质上是演化型的，开发过程是迭代的。构件集成模型由软件的需求分析和定义、体系结构设计、构件库建立、应用软件构建，以及测试和发布5个阶段组成，如图2-6所示。
基于构件的开发活动从标识候选构件开始，通过搜查已有构件库，确认所需要的构件是否已经存在。如果已经存在，则从构件库中提取出来复用；否则采用面向对象的方法开发它。之后在提取出来的构件通过语法和语义检查后，将这些构件通过代码组装到一起实现系统，这个过程是迭代的。基于构件的开发方法使得软件开发不再一切从头开发，开发的过程就是构件组装的过程，维护的过程就是构件升级、替换和扩充的过程。其优点是构件集成模型导致了软件的复用，提高了软件开发的效率。
由于采用自定义的组装结构标准，缺乏通用的组装结构标准，这样就引入了比较大的风险。可重用性和软件高效性不容易协调，这就需要比较有开发经验的开发人员，而一般的开发人员很难开发出令客户满意的软件。由于过分依赖于构件，所以构件库的质量影响着产品质量。
构件集成模型融合了螺旋模型的很多特征，支持软件开发的迭代方法。这种面向复用的过程模型，最明显的优势是减少了需要开发的软件数量，加快了软件交付，从而降低了开发成本，同时也降低了开发风险。当然，它的成功主要是依赖于可复用软件构件，以及能集成这些软件构件的框架。
