软件开发模型研究综述

　　引言 正如任何事物一样，软件也有其孕育、诞生、成长"成熟和衰亡的生存过程，一般称其为软件的生命周期\软件生命周期一般分为六个步骤，即制定计划、需求分析、设计、编码、测试及运行和维护。软件开发的各个阶段之间的关系不可能是顺序的、线性的，相反这个过程应该是带有反馈的迭代过程。在软件工程中，这个复杂的过程是用软件开发模型来描述和表示的。

　　软件开发模型是跨越整个软件生存周期的系统开发、运行、维护所实施的全部工作和任务的结构框架，给出了软件开发活动各阶段之间的关系。目前，常见的软件开发模型大致可分为三种类型：

　　(1)以软件需求完全确定为前提的瀑布模型(WaterfallModel)

　　(2)在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型，如螺旋模型(SpiralModel)等c

　　(3)以形式化开发方法为基础的变换模型(TransformationalModel)

　　2瀑布模型

　　瀑布模型即生存周期模型，其核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，采用结构化的分析与设计方法，将逻辑实现与物理实现分开。瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、运行和维护六个步骤，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。采用瀑布模型的软件过程如图1所示。

　　瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。瀑布模型的本质是：一次通过，即每个活动只做一次，最后得到软件产品，也称作“线性顺序模型”或者“传统生命周期”[2]，其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容，给出该项活动的工作成果，作为输出传给下一项活动;对该项活动实施的工作进行评审，若其工作得到确认，则继续下一项活动，否则返回前项，甚至更前项的活动进行返工。

　　瀑布模型有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和工具的研究与使用，从而提高了大型软

　　件项目开发的质量和效率。然而软件开发的实践表明，上述各项活动之间并非完全是自上而下，呈线性图式。因此，瀑布模型存在严重的缺陷。

　　(1)由于开发模型呈线性，所以当开发成果尚未经过测试时，用户无法看到软件的效果。这样，软件与用户见面的时间间隔较长，也增加了一定的风险。

　　(2)在软件开发前期末发现的错误传到后面的开发活动中时，可能会扩散，进而可能会造成整个软件项目开发失败。

　　(3)在软件需求分析阶段，就完全确定用户的所有需求是比较困难的，甚至可以说是不太可能的。

　　3螺旋模型

　　螺旋模型将瀑布模型和演化模型(EvolutionModel)结合起来，不仅体现了两个模型的优点，而且还强调了其他模型均忽略了的风险分析。螺旋模型的每一周期都包括需求定义、风险分析、工程实现和评审四个阶段，由这四个阶段进行迭代，软件开发过程每迭代一次，软件开发又前进一个层次。采用螺旋模型的软件过程如图2所示。

　　螺旋模型基本做法是在“瀑布模型”的每一个开发阶段前，引入一个非常严格的风险识别、风险分析和风险控制。它把软件项目分解成一个个小项目，每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。

　　螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应。因此，螺旋模型特别适用于庞大而复杂、具有高风险的系统，对于这些系统，风险是软件开发不可忽视的、潜在的不利因素，它可能在不同程度上损害软件开发过程，影响软件产品的质量。减小软件风险的目标是在造成危害之前，及时对风险进行识别、分析，决定采取何种对策，进而消除或减少风险的损害。

　　与瀑布模型相比，螺旋模型支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供了方便，有助于提高目标软件的适应能力，为项目管理人员及时调整管理决策提供了便利，从而降低了软件开发风险。

　　但是，我们不能说螺旋模型绝对比其他模型优越，事实上，螺旋模型也有其自身的缺点：

　　(1)采用螺旋模型，需要具有相当丰富的风险评估经验和专门知识。在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失。

　　(2)过多的迭代次数会增加开发成本，延迟提交时间。机系统能够接受的程序系统。采用变换模型的软件过程如图3所示。

　　4变换模型

　　变换模型是基于形式化规格说明语言及程序变换的软件

　　开发模型。它采用形式化的软件开发方法，对形式化的软件规

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

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

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

　　5喷泉模型

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

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

　　喷泉模型不像瀑布模型那样，需要分析活动结束才开始设计活动，设计活动结束后才开始编码活动，喷泉模型的各个阶段没有明显的界限，开发人员可以同步进行开发"其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程"由于喷泉模型在各个开发阶段是重叠的，因此，在开发过程中，需要大量的开发人员，不利于项目的管理;要求对文档的管理较为严格，审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料"

　　6智能模型

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

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

　　智能模型以知识作为处理对象，这些知识既有理论知识也有特定领域的经验，在开发过程中需要将这些知识从书本中和特定领域的知识库中抽取出来(即知识获取)，选择适当的方法进行编码(即知识表示)建立知识库[4]。将模型、软件工程知识与特定领域的知识分别存入数据库。在这个过程中需要系统开发人员与领域专家的密切合作。

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

　　7增量模型

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

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

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

　　8WINWIN模型

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

　　本质上，抛锚点表示了项目遍历螺旋时的三个不同的进展视图，第一个抛锚点称为“生存周期目标”，定义了一组针对每个主要软件工程活动的目标;第二个抛锚点称为“生存周期体系结构”，建立了当系统和软件体系结构被定义时必须满足的

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

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

　　9原型实现模型

　　原型实现模型是从需求收集开始，开发者和客户在一起定义软件的总体目标，标识出己知的需求，并规划出需要进一步定义的区域。然后是“快速设计”，快速设计集中于软件中那些对用户/客户可见的部分的表示，这将导致原型的创建，并由用户/客户评估并进一步精化待开发软件的需求。

　　逐步调整原型使其满足客户的要求，而同时也使开发者对将要做的事情有更好的理解，这个过程是迭代的。其流程从听取客户意见开始，随后是建造/修改原型，客户测试运行原型，然后回头往复循环直到客户对原型满意为止。采用原型实现模型的软件过程如图8所示。 

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

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

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

　　10RAD模型

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

　　RAD模型各个活动期所要完成的任务是:

　　(1)业务建模：以什么信息驱动业务过程运作?要生成什么信息?谁生成它?信息流的去向?由谁处理?可以辅之以

　　数据流图。

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

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

　　(4)应用程序生成：利用第四代语言(4GL)写出处理程序，重用己有构件或创建新的可重用构件，利用环境提供的工具,自动生成、构造出整个应用系统

　　(5)测试与交付，由于大量重用，一般只作总体测试，但新创建的构件还是要测试的。

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

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

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

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

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

　　11并发开发模型

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

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

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

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

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

　　12基于构件的开发模型

　　基于构件的开发模型利用模块化方法，将整个系统模块化，并在一定构件模型的支持下，复用构件库中的一个或多个软件构件，通过组合手段高效率、高质量地构造应用软件系统的过程。基于构件的开发模型融合了螺旋模型的许多特征，本质上是演化型的，开发过程是迭代的。基于构件的开发模型由软件的需求分析和定义、体系结构设计、构件库建立、应用软件构建、测试和发布五个阶段组成。采用基于构件的开发模型的软件过程如图11所示。

　　构件作为重要的软件技术和工具得到极大的发展，这些新技术和工具有Microsoft的DC0M、SU?的EJB、0MG的C0RBA等。基于构件的开发活动从标识候选构件开始，通过搜查已有构件库，确认所需要的构件是否已经存在，如果已经存在，就从构件库中提取出来复用;如果不存在，就采用面向对象方法开发它。之后利用提取出来的构件通过语法和语义检查后，将这些构件通过胶合代码组装到一起实现系统，这个过程是迭代的。

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

　　13基于体系结构的开发模型

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

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

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

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

　　基于体系结构的开发模型和基于构件的开发模型都是在体系结构的基础上进行构件的组装而得到软件系统。基于构

　　件的开发模型主要关注运行级构件和它们之间的互操作性，提供了一种自底向上的、基于预先定制好的构件来构造应用系统的途径;不过基于构件的开发方法局限在构件的规范上，缺少系统化的指导开发过程的方法学。基于体系结构的开发方法从系统的总体结构入手，将一个系统的体系结构显示化，以在高抽象层次处理诸如全局组织和控制结构、功能到计算元素的分配、计算元素间的高层交互等设计问题。法强调适应性而非预测性，强调以人为中心而非以流程为中心，强调对变化的适应和对人性的关注。它的特点是：轻载、基于时间、JustEnough、并行、基于构件的软件过程。在所有敏捷方法中，XP方法(eXtremeProgramming)是最引人注目的一种轻型开发方法，它规定了一组核心价值和方法，消除了大多数重量型过程的不必要产物，建立了一个渐进型开发过程。XP方法将开发阶段的4个活动(分析、设计、编码和测试)混合在一起，在全过程中采用迭代增量开发、反馈修正、反复测试，把软件生命周期划分为用户故事、体系结构、发布计划、交互、接受测试和小型发布六个阶段。采用基于体系结构的开发模型的软件过程如图13所示。

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

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

　　XP开发方法中有许多新思路，如采用“用户故事”代替15第四代技术

　　第四代技术(4GT)包含了一系列的软件工具，它们都具有一个共同点：能使软件工程师在较高级别上规约软件的某些特征。然后工具根据开发者的规约自动生成源代码。毫无疑问软件在越高级别上被规约，就能越快地构造出程序。软件工程的4GT模型集中于规约软件的能力——使用特殊的语言形式或采用客户可以理解的术语描述待解决的问题的图形符号体系。

　　像其它模型一样，4GT也是从需求收集这一步开始的，理想情况下，客户能够描述出需求，而这些需求能被直接转换成可操作原型。但这是不现实的，客户可能不能完全确定需要什?敏捷方法是近几年兴起的一种轻量级的开发方法，敏捷方n!么，在规约己知的事实下可能出现二义性。因此，其它模型中所自己的需求;XP模型的优点是采用简单计划策略，不需要长期计划和复杂模型，开发周期短;在全过程采用迭代增量开发、反馈修正和反复测试的方法，软件质量有保证;其最大优点是能够适应用户经常变化的需求，提供给用户满意的高质量软件。

　　描述的用户/开发者对话在4GT方法中仍然是一个必要的组成部分,要将一个4GT实现变成最终产品，开发者还必须进行彻底的测试，开发有意义的文档，并且同样要完成其它模型中同样要求的所有集成活动。此外，采用4GT开发的软件还必须以使维护能够被迅速完成的方式建造。

　　像其它所有软件过程模型一样，4GT模型也有其优点和缺点。其优点是：缩短了软件开发时间，提高了建造软件的效率;对很多不同的应用领域提供了一种可行性途径和解决方案。其缺点是：用工具生成的源代码可能是“低效”的'生成的大型软件的可维护性目前还令人怀疑'在某些情况下可能需要更多的时间。

　　总之，第四代技术己经成为软件工程的一个重要方法。当与基于构件的开发方法结合起来时，4GT模型可能成为软件开发的主流方法。

　　16总结

　　软件工程是集成计算机软件开发的过程、方法和工具的学科。己经产生了一系列的软件工程过程模型，各自展示了其优点和弱点，但是，它们均有一系列共同的阶段。软件过程模型发展经历了以下阶段。

　　首先，以软件需求完全确定为前提的第一代软件过程模型，如瀑布模型等。这类开发模型的特点是软件需求在开发阶段已经被完全确定，将生命周期的各项活动依顺序固定，强调开发的阶段性。这样带来的缺点是：开发后期要改正早期存在的问题需要付出很高的代价'用户需要等待较长时间才能够看到软件产品，增加了风险系数'开发过程如果存在阻塞问题，则影响开发效率。其次，在开始阶段只能提供基本需求的渐进式开发模型，如螺旋模型、原型实现模型等。这类开发模型的特点是：软件开发开始阶段只有基本的需求，软件开发过程的各个活动是迭代的，通过迭代过程实现软件的逐步演化，最终得到软件产品。再次，引入了风险管理，采取早期预防措施，增加项目成功几率，提高软件质量。其缺点是：由于需求的不完全性，这给软件的总体设计带来了困难和削弱了产品设计的完整性;要求较高的风险技能管理水平。再次，是以体系结构为基础的基于构件组装的开发模型，如基于构件的开发模型、基于体系结构的开发模型等。