软件开发模型介绍与对比分析

常用的软件开发模型

软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。

软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。对于不同的软件系统，可以采用不同的开发方法、使用不同的程序设计语言以及各种不同技能的人员参与工作、运用不同的管理方法和手段等，以及允许采用不同的软件工具和不同的软件工程环境。

1. 瀑布模型-最早出现的软件开发模型

1970年温斯顿?罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。

瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。从本质来讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好“返回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一个阶段，这也是瀑布开发名称的由来。

瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。对于经常变化的项目而言，瀑布模型毫无价值。（采用瀑布模型的软件过程如图所示）

瀑布模型的优缺点

1、瀑布模型有以下优点：

1）为项目提供了按阶段划分的检查点。

2）当前一阶段完成后，您只需要去关注后续阶段。

3）可在迭代模型中应用瀑布模型。

增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。

2、瀑布模型有以下缺点：

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

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

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

瀑布模型的客户需求

尽管瀑布模型招致了很多批评，但是它对很多类型的项目而言依然是有效的，如果正确使用，可以节省大量的时间和金钱。对于您的项目而言，是否使用这一模型主要取决于您是否能理解客户的需求以及在项目的进程中这些需求的变化程度，对于经常变化的项目而言，瀑布模型毫无价值，对于这种情况，您可以考虑其他的架构来进行项目管理，比如名为螺旋模型（spiral model）的方法。

在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。

瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于：

（1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；

（2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；

（3）早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

按照瀑布模型的阶段划分，软件测试可以分为单元测试，集成测试，系统测试。

2. 迭代模型

早在20世纪50年代末期，软件领域中就出现了迭代模型。最早的迭代过程可能被描述为“分段模型（stagewise model）”，其背景是H.D.Benington领导的美国空军SAGE项目。

迭代模型是RUP（Rational Unified Process，统一软件开发过程，统一软件过程)推荐的周期模型。在RUP中，迭代被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。

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

在现代过程方法XP（eXtreme Programming，极限编程）、RUP无一例外地都推荐、主张采用能显著减少风险的迭代模型。美国国防部原本提倡瀑布过程和观点，在发现那么多采用了瀑布模型的失败的项目之后，不但放弃了对它的要求，而且从1 994年的报告开始，积极地鼓励采用更加现代化的迭代模型来取代瀑布模型做法。同时，中国中科院也提倡选用迭代模型。

对众多的开发模型和过程方法，及权威机构的看法，企业应选择什么样的开发模型，应慎重对从以下几方面进行考虑：

1、RUP虽然内容极其丰富，定义了选起、精化、构建、产品化4个阶段和业务

建模、需求、分析设计、实现、测试、部署等9个工种，提供了一大堆的文档模板，但极易让人误解是重型的过程，实施推广有一定难度。

2、再次，在质量管理方面：以实现系统架构、核心功能目标的迭代产品生的工作成果作为质量控制重点。每次迭代进行系统集成、系统测试，达到对软件质量的持续验证。每次系统测试，需要回归测试前一次迭代遗留发现的问题。每次迭代发布的小版本组织客户（包括内部客户、外部客户）进行评价，通过演示操作等方式，评价该次迭代是否达到预定的目标，并以此为依据来制定下一次迭代的目标。

3、最后，在其他方面：每次迭代成果须进行配置管理，版本控制很重要。在整个迭代过程中风险无处不在，建议每周作一次风险跟踪。同时通过重点关注进度、工作量、满意度、缺陷等数据收集，关注每次迭代情况。

总之，选择一个合适的生命周期模型，并应用正确的方法，对于任何软件项目的成功是至关重要。企业在选择开发模型应从项目时间要求、需求明确程度、风险状况等选择合适的生命周期模型。

迭代模型的选择使用条件

1、在项目开发早期需求可能有所变化。

2、分析设计人员对应用领域很熟悉。

3、高风险项目。

4、用户可不同程度地参与整个项目的开发过程。

5、使用面向对象的语言或统一建模语言（Unified Modeling Language，UML）。

6、使用CASE（Computer Aided Software Engineering，计算机辅助软件工程）工具，如Rose（Rose是非常受欢迎的物件软体开发工具。）。

7、具有高素质的项目管理者和软件研发团队。

迭代模型的优点

与传统的瀑布模型相比较，迭代过程具有以下优点：

1）降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。

2）降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。

3）加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工

作会更有效率。

4）由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续

阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。

3. 螺旋模型

1988年，BarryBoehm正式发表了软件系统开发的"螺旋模型"，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。

螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：

（1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；

（2）风险分析：分析评估所选方案，考虑如何识别和消除风险；

（3）实施工程：实施软件开发和验证；

（4）客户评估：评价开发工作，提出修正建议，制定下一步计划。

螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。但是，螺旋模型也有一定的限制条件，具体如下：

（1）螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。

（2）如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。

（3）软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险

一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段。

螺旋模型的缺点:

很难让用户确信这种演化方法的结果是可以控制的。建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。

螺旋模型的项目适用：

对于新近开发，需求不明确的情况下，适合用螺旋模型进行开发，便于风险控制和需求变更！

4. 变换模型

变换模型是基于形式化规格说明语言及程序变换的软件开发模型，它采用形式化的软件开发方法对形式化的软件规格说明进行一系列自动或半自动的程序变换，最后映射为计算机系统能够接受的程序系统。采用变换模型的软件过程如图1-5所示。

图1-5 采用变换模型的软件过程

为了确认形式化规格说明与软件需求的一致性，往往以形式化规格说明为基础开发一个软件原型，用户可以从人机界面、系统主要功能和性能等几个方面对原型进行评审。必要时，可以修改软件需求、形式化规格说明和原型，直至原型被确认为止。这时软件开发人员即可对形式化的规格说明进行一系列的程序变换，直至生成计算机系统可以接受的目标代码。

“程序变换”是软件开发的另一种方法，其基本思想是把程序设计的过程分为生成阶段和改进阶段。首先通过对问题的分析制定形式规范并生成一个程序，通常是一种函数型的“递归方程”。然后通过一系列保持正确性的源程序到源程序的变换，把函数型风格转换成过程型风格并进行数据结构和算法的求精，最终得到一个有效的面向过程的程序。这种变换过程是一种严格的形式推导过程，所

以只需对变换前的程序的规范加以验证，变换后的程序的正确性将由变换法则的正确性来保证。

变换模型的优点是解决了代码结构经多次修改而变坏的问题，减少了许多中间步骤（如设计、编码和测试等）。但是变换模型仍有较大局限，以形式化开发方法为基础的变换模型需要严格的数学理论和一整套开发环境的支持，目前形式化开发方法在理论、实践和人员培训方面距工程应用尚有一段距离。

5. 喷泉模型

喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。该模型认为软件开发过程自下而上周期的各阶段是相互重叠和多次反复的，就像水喷上去又可以落下来，类似一个喷泉。各个开发阶段没有特定的次序要求，并且可以交互进行，可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏。采用喷泉模型的软件过程如图1-6所示。

图1-6 采用喷泉模型的软件过程

喷泉模型主要用于面向对象的软件项目，软件的某个部分通常被重复多次，相关对象在每次迭代中随之加入渐进的软件成分。各活动之间无明显边界，例如设计和实现之间没有明显的边界，这也称为“喷泉模型的无间隙性”。由于对象概念的引入，表达分析、设计及实现等活动只用对象类和关系，从而可以较容易地实现活动的迭代和无间隙。

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

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

6. 智能模型

智能模型也称为“基于知识的软件开发模型”，它把瀑布模型和专家系统结合在一起，利用专家系统来帮助软件开发人员的工作。该模型应用基于规则的系统，采用归纳和推理机制，使维护在系统规格说明一级进行。这种模型在实施过程中以软件工程知识为基础的生成规则构成的知识系统与包含应用领域知识规则的专家系统相结合，构成这一应用领域软件的开发系统。采用智能模型的软件过程如图1-7所示。

图1-7 采用智能模型的软件过程

智能模型所要解决的问题是特定领域的复杂问题，涉及大量的专业知识，而开发人员一般不是该领域的专家，他们对特定领域的熟悉需要一个过程，所以软件需求在初始阶段很难定义得很完整。因此，采用原型实现模型需要通过多次迭代来精化软件需求。

智能模型以知识作为处理对象，这些知识既有理论知识，也有特定领域的经验。在开发过程中需要将这些知识从书本中和特定领域的知识库中抽取出来（即知识获取），选择适当的方法进行编码（即知识表示）建立知识库。将模型、软

件工程知识与特定领域的知识分别存入数据库，在这个过程中需要系统开发人员与领域专家的密切合作。

智能模型开发的软件系统强调数据的含义，并试图使用现实世界的语言表达数据的含义。该模型可以勘探现有的数据，从中发现新的事实方法指导用户以专家的水平解决复杂的问题。它以瀑布模型为基本框架，在不同开发阶段引入了原型实现方法和面向对象技术以克服瀑布模型的缺点，适应于特定领域软件和专家决策系统的开发。

7. 增量模型

增量模型融合了瀑布模型的基本成分（重复应用）和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时，第1个增量往往是核心的产品，即第1个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。采用增量模型的软件过程如图1-8所示。

增量模型与原型实现模型和其他演化方法一样，本质上是迭代的，但与原型实现不一样的是其强调每一个增量均发布一个可操作产品。早期的增量是最终产品的“可拆卸”版本，但提供了为用户服务的功能，并且为用户提供了评估的平台。增量模型的特点是引进了增量包的概念，无须等到所有需求都出来，只要某个需求的增量包出来即可进行开发。虽然某个增量包可能还需要进一步适应客户的需求并且更改，但只要这个增量包足够小，其影响对整个项目来说是可以承受的。

图1-8 采用增量模型的软件过程

采用增量模型的优点是人员分配灵活，刚开始不用投入大量人力资源。如果核心产品很受欢迎，则可增加人力实现下一个增量。当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径。这样即可先发布部分功能给客户，对客户起到镇静剂的作用。此外，增量能够有计划地管理技术风险。增量模型的缺点是如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。

8. 快速原型模型（Rapid Prototype Model）

快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。

显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。

快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。

9. 原型实现模型

原型实现模型从需求收集开始，开发者和客户在一起定义软件的总体目标，标识出已知的需求，并规划出需要进一步定义的区域。然后是“快速设计”，即集中于软件中那些对用户／客户可见的部分的表示。这将导致原型的创建，并由用户／客户评估并进一步精化待开发软件的需求。逐步调整原型使其满足客户的要求，而同时也使开发者对将要做的事情有更好的理解。这个过程是迭代的，其流程从听取客户意见开始，随后是建造／修改原型、客户测试运行原型。然后往复循环，直到客户对原型满意为止。采用原型实现模型的软件过程如图1-10所示。

图1-10 采用原型实现模型的软件过程

原型实现模型的最大特点是能够快速实现一个可实际运行的系统初步模型，供开发人员和用户进行交流和评审，以便较准确地获得用户的需求。该模型采用逐步求精方法使原型逐步完善，即每次经用户评审后修改、运行，不断重复得到双方认可。这个过程是迭代过程，它可以避免在瀑布模型冗长的开发过程中看不见产品雏形的现象。其优点一是开发工具先进，开发效率高，使总的开发费用降低，时间缩短；二是开发人员与用户交流直观，可以澄清模糊需求，调动用户的积极参与，能及早暴露系统实施后潜在的一些问题；三是原型系统可作为培训环境，有利于用户培训和开发同步，开发过程也是学习过程。

原型实现模型的缺点是产品原型在一定程度上限制了开发人员的创新，没有考虑软件的整体质量和长期的可维护性。由于达不到质量要求产品可能被抛弃，而采用新的模型重新设计，因此原型实现模型不适合嵌入式、实时控制及科学数值计算等大型软件系统的开发。

增量模型和原型模型都是从概要需求出发开发的，但二者有明显不同。增量模型是从一些不完整的系统需求出发开始开发，在开发过程中逐渐发现新的需求。然后进一步充实完善该系统，使之成为实际可用的系统；原型开发的目的是为了发现并建立一个完整并经过证实的需求规格说明，然后以此作为正式系统的开发基础。因此原型开发阶段的输出是需求规格说明，这是为了降低整个软件生成期的费用而拉大需求分析阶段的一种方法，大部分原型是“用完就扔”的类型。

10. 演化模型(incremental model)

主要针对事先不能完整定义需求的软件开发。用户可以给出待开发系统的核心需求，并且当看到核心需求实现后，能够有效地提出反馈，以支持系统的最终设计和实现。软件开发人员根据用户的需求，首先开发核心系统。当该核心系统投入运行后，用户试用之，完成他们的工作，并提出精化系统、增强系统能力的需求。软件开发人员根据用户的反馈，实施开发的迭代过程。第一迭代过程均由需求、设计、编码、测试、集成等阶段组成，为整个系统增加一个可定义的、可管理的子集。

在开发模式上采取分批循环开发的办法，每循环开发一部分的功能，它们成为这个产品的原型的新增功能。于是，设计就不断地演化出新的系统。实际上，这个模型可看作是重复执行的多个“瀑布模型”。

“演化模型”要求开发人员有能力把项目的产品需求分解为不同组，以便分批循环开发。这种分组并不是绝对随意性的，而是要根据功能的重要性及对总体设计的基础结构的影响而作出判断。有经验指出，每个开发循环以六周到八周为适当的长度。11. 混合模型（hybrid model）

过程开发模型又叫混合模型（hybrid model），或元模型（meta-model）,把几种不同模型组合成一种混合模型，它允许一个项目能沿着最有效的路径发展，这就是过程开发模型（或混合模型）。实际上，一些软件开发单位都是使用几种不同的开发方法组成他们自己的混合模型。

12. WINWIN模型

WINWIN模型融合了螺旋模型的基本成分和原型实现的迭代特征，强调风险分析和标识。通过早期谈判使客户和开发者之间达成一致协议，它将变成进展到软件和系统定义的关键标准。WINWIN模型引入了3个里程碑，称为“抛锚点”。它可帮助建立一个生命周期的完全性，并提供在软件项目向前进展前的决策里程碑。采用WINWIN模型的软件过程如图1-9所示。

图1-9 采用WINWIN模型的软件过程

本质上，抛锚点表示了项目遍历螺旋时的3个不同的进展视图，第1个抛锚点称为“生存周期目标”，定义了一组针对每个主要软件工程活动的目标；第2个抛锚点称为“生存周期体系结构”，建立了当系统和软件体系结构被定义时必须满足的目标；第3个抛锚点称为“初始操作能力”，它表示一组目标，这些目标和将要安装／销售软件的安装前场地准备和将使用该软件的各方所需的帮助相关联。

WINWIN模型强调风险分析和标识，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应。采用WINWIN模型的优点是客户和开发者达到一种平衡，实现双赢，但是需要额外的谈判技巧。

螺旋模型提出了强调客户交流的一个框架活动，该活动的目标是从客户处诱导出项目需求。在理想情况下，开发人员简单地询问客户需要什么，而客户提供足够的细节进行下去，不幸的是这种情形很少发生。而在WINWIN模型中，客户和开发人员进入一个谈判过程，客户被要求在成本和应市之间的约束下平衡功能、性能和其他产品或系统特征。最好的谈判追求“双赢”结果，即通过谈判客户获得大部分系统的功能，而开发人员则获得现实和可达到的预算和时限。13. RAD模型

RAD（快速应用开发）模型是一个增量型的软件开发过程模型，强调极短的开发周期。该模型是瀑布模型的一个“高速”变种，通过大量使用可复用构件，采用基于构件的建造方法赢得了快速开发。如果正确地理解了需求，而且约束了项目的范围，利用这种模型可以很快创建出功能完善的信息系统。其流程从业务建模开始，随后是数据建模、过程建模、应用生成、测试及反复。采用RAD模型的软件过程如图1-11所示。

图1-11 采用RAD模型的软件过程

RAD模型各个活动期所要完成的任务如下。

（1）业务建模

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

（2）数据建模

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

（3）过程建模

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

（4）应用程序生成

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

（5）测试与交付

由于大量重用，一般只做总体测试，但新创建的构件还是要测试的。

与瀑布模型相比，RAD模型不采用传统的第3代程序设计语言来创建软件，而是采用基于构件的开发方法复用已有的程序结构（如果可能）或使用可复用构件和或创建可复用的构件（如果需要）。在所有情况下，均使用自动化工具辅助

软件创造。很显然，加在一个RAD模型项目上的时间约束需要“一个可伸缩的范围”。如果一个业务能够被模块化使得其中每一个主要功能均可以在不到3个月的时间内完成，则其是RAD的一个候选者。每一个主要功能可由一个单独的RAD 组来实现，最后集成起来形成一个整体。

RAD模型通过大量使用可复用构件加快了开发速度，对信息系统的开发特别有效。但是与所有其他软件过程模型一样，RAD方法有如下缺陷。

① 并非所有应用都适合RAD。RAD模型对模块化要求比较高，如果有哪一个功能不能被模块化，那么建造RAD所需要的构件就会有问题。如果高性能是一个指标且该指标必须通过调整接口使其适应系统构件才能赢得，RAD方法也有可能不能奏效。

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

③ RAD只能用于信息系统开发，不适合技术风险很高的情况。当一个新应用要采用很多新技术或当新软件要求与已有的计算机程序的高互操作性时，这种情况就会发生。

14. 并发开发模型

并发开发模型也称为“并发工程”，它关注于多个任务的并发执行，表示为一系列的主要技术活动、任务及其相关状态。并发过程模型由客户要求、管理决策，评审结果驱动，不是将软件工程活动限定为一个顺序的事件序列，而是定义一个活动网络，网络上的每一个活动均可与其他活动同时发生。这种模型可以提供一个项目的当前状态的准确视图。采用并发开发模型的软件过程中一个活动的示意如图1-12所示。

图1-12 并发过程模型的一个活动

并发过程模型定义了一系列事件，对于每一个软件工程活动，它们触发一个状态到另一个状态的变迁。当它应用于客户机／服务器系统时，并发过程模型在两维上定义活动，即一个系统维和一个构件维。其并发性通过如下两种方式得到。

① 系统维和构件维活动同时发生，并可以使用面向状态的方法进行建模。

② 一个典型的客户／服务器应用通过多个构件实现，其中每个构件均可以并发设计并实现。

并发开发模型试图根据传统生命周期的主要阶段来追踪项目的状态，项目管理者根本不可能了解项目的状态，因而需要使用比较简单的模型来追踪非常复杂的项目活动。并发开发模型使用状态图（表示一个加工状态）来表示与一个特定事件（如在开发后期需求的一个修改）相关的活动之间存在的并发关系，但它不能捕获到贯穿于一个项目中所有软件开发和管理活动的大量并发。

大多数软件开发过程模型均为时间驱动，越到模型的后端，就越到开发过程的后一阶段，而一个并发过程模型是由用户要求、管理决策和结果复审驱动的。并发开发模型在软件开发全过程活动的并行化，打破了传统软件开发的各阶段分割封闭的观念。强调开发人员团队协作，注重分析和设计等前段开发工作，从而避免了不必要的返工。其优点是可用于所有类型的软件开发，而对于客户／服务器结构更加有效，可以随时查阅到开发的状态。

15. 基于构件的开发模型

基于构件的开发模型利用模块化方法将整个系统模块化，并在一定构件模型的支持下复用构件库中的一个或多个软件构件，通过组合手段高效率、高质量地

构造应用软件系统的过程。基于构件的开发模型融合了螺旋模型的许多特征，本质上是演化形的，开发过程是迭代的。基于构件的开发模型由软件的需求分析和定义、体系结构设计、构件库建立、应用软件构建，以及测试和发布5个阶段组成，采用这种开发模型的软件过程如图1-13所示。

图1-13 采用基于构件的开发模型的软件过程

构件作为重要的软件技术和工具得到极大的发展，这些新技术和工具有Mic rosoft的DCOM、Sun的EJB，以及OMG的CORBA等。基于构件的开发活动从标识候选构件开始，通过搜查已有构件库，确认所需要的构件是否已经存在。如果已经存在，则从构件库中提取出来复用；否则采用面向对象方法开发它。之后利用提取出来的构件通过语法和语义检查后将这些构件通过胶合代码组装到一起实

现系统，这个过程是迭代的。

基于构件的开发方法使得软件开发不再一切从头开发，开发的过程就是构件组装的过程，维护的过程就是构件升级、替换和扩充的过程。其优点是构件组装模型导致了软件的复用，提高了软件开发的效率。构件可由一方定义其规格说明，被另一方实现。然后供给第三方使用，构件组装模型允许多个项目同时开发，降低了费用，提高了可维护性，可实现分步提交软件产品。

由于采用自定义的组装结构标准，缺乏通用的组装结构标准，因而引入了较大的风险。可重用性和软件高效性不易协调，需要精干的有经验的分析和开发人员，一般开发人员插不上手。客户的满意度低，并且由于过分依赖于构件，所以构件库的质量影响着产品质量。

16. 基于体系结构的开发模型

基于体系结构的开发模型是以软件体系结构为核心，以基于构件的开发方法为基础。然后采用迭代增量方式进行分析和设计，将功能设计空间映射到结构设计空间，再由结构设计空间映射到系统设计空间的过程。该开发模型把软件生命周期分为软件定义、需求分析和定义、体系结构设计、软件系统设计和软件实现5个阶段，采用这种开发模型的软件过程如图1-14所示。

图1-14 采用基于体系结构的开发模型的软件过程

在基于体系结构的开发过程中，首先是基于体系结构的需求获取和分析，将软件体系结构的概念引入到需求空间，从而为分析阶段到设计阶段的过渡提供更好的支持。在需求分析结果的基础上，进行体系结构的设计。考虑系统的总体结构及系统的构成元素，根据构成元素的语法和语义在已确定的构件库中寻找匹配的构件。当不存在符合要求的构件时，则根据具体情况组装合成新构件或者购买新构件或者根据需要开发新构件而得到满足需求的构件。在经过语法和语义检查后，将这些构件通过胶合代码组装到一起实现整个软件系统。在实践中，整个开发过程呈现多次迭代性。

在传统的软件生命周期中，软件需求分析和定义完成后紧接的是软件系统的设计和实现。在这种传统的开发方法中，如果软件需求不断变化，最终软件产品可能与初始原型相差很大。而基于体系结构的开发模型有严格的理论基础和工程原则，是以体系结构为核心。体系结构为软件需求与软件设计之间架起了一座桥

梁，解决了软件系统从需求到实现的平缓过渡，提高了软件分析设计的质量和效率。

基于体系结构的开发模型的优点是通过对体系结构的设计，使得软件系统结构框架更清晰，有利于系统的设计、开发和维护，并且软件复用从代码级的复用提升到构件和体系结构级的复用。

基于体系结构的开发模型和基于构件的开发模型都是在体系结构的基础上

进行构件的组装而得到软件系统，前者主要关注运行级构件及其之间的互操作性，提供了一种自底向上且基于预先定制好的构件来构造应用系统的途径；后者局限在构件的规范上，缺少系统化的指导开发过程的方法学。基于体系结构的开发方法从系统的总体结构入手，将一个系统的体系结构显示化，以在高抽象层次处理诸如全局组织和控制结构、功能到计算元素的分配、计算元素间的高层交互等设计问题。

17. XP方法

敏捷方法是近几年兴起的一种轻量级的开发方法，它强调适应性而非预测性、强调以人为中心，而不以流程为中心，以及对变化的适应和对人性的关注，其特点是轻载、基于时间、Just Enough、并行并基于构件的软件过程。在所有的敏捷方法中，XP（eXtreme Programming）方法是最引人注目的一种轻型开发方法。它规定了一组核心价值和方法，消除了大多数重量型过程的不必要产物，建立了一个渐进型开发过程。该方法将开发阶段的4个活动（分析、设计、编码和测试）混合在一起，在全过程中采用迭代增量开发、反馈修正和反复测试。它把软件生命周期划分为用户故事、体系结构、发布计划、交互、接受测试和小型发布6个阶段，采用这种开发模型的软件过程如图1-15所示。

图1-15 采用XP方法的软件过程

XP模型通过对传统软件开发的标准方法进行重新审视，提出了由一组规则组成的一些简便易行的过程。由于这些规则是通过在实践中观察使软件高效或缓慢的因素而得出的，因此它既考虑了保持开发人员的活力和创造性，又考虑了开发过程的有组织、有重点和持续性。XP模型是面向客户的开发模型，重点强调用户的满意程度。开发过程中对需求改变的适应能力较高，即使在开发的后期，也可较高程度地适应用户的改变。

XP开发模型与传统模型相比具有很大的不同，其核心思想是交流（Communi cation）、简单（Simplicity）、反馈（Feedback）和进取（Aggressiveness）。XP开发小组不仅包括开发人员，还包括管理人员和客户。该模型强调小组内成员之间要经常进行交流，在尽量保证质量可以运行的前提下力求过程和代码的简单化；来自客户、开发人员和最终用户的具体反馈意见可以提供更多的机会来调整设计，保证把握正确的开发方向；进取则包含于上述3个原则中。

XP开发方法中有许多新思路，如采用“用户故事”代替传统模型中的需求分析，“用户故事”由用户用自己领域中的词汇并且不考虑任何技术细节准确地表达自己的需求。XP模型的优点如下。

① 采用简单计划策略，不需要长期计划和复杂模型，开发周期短。

② 在全过程采用迭代增量开发、反馈修正和反复测试的方法，软件质量有保证。

③ 能够适应用户经常变化的需求，提供用户满意的高质量软件。

各种模型的比较

每个软件开发组织应该选择适合于该组织的软件开发模型，并且应该随着当前正在开发的特定产品特性而变化，以减小所选模型的缺点，充分利用其优点，下表列出了几种常见模型的优缺点。

各种模型的优点和缺点

瀑布模型文档驱动系统可能不满足客户的需求

快速原型模型关注满足客户需求可能导致系统设计差、效率低，难于维护