常用软件开发模型比较分析.doc

常用软件开发模型比较分析正如任何事物一样，软件也有其孕育、诞生、成长、成熟和衰亡的生存过程，一般称其为“软件生命周期”。软件生命周期一般分为6个阶段，即制定计划、需求分析、设计、编码、测试、运行和维护。软件开发的各个阶段之间的关系不可能是顺序且线性的，而应该是带有反馈的迭代过程。在软件工程中，这个复杂的过程用软件开发模型来描述和表示。软件开发模型是跨越整个软件生存周期的系统开发、运行和维护所实施的全部工作和任务的结构框架，它给出了软件开发活动各阶段之间的关系。目前，常见的软件开发模型大致可分为如下3种类型。 以软件需求完全确定为前提的瀑布模型（Waterfall Model）。 在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型，如螺旋模型（Spiral Model）。 以形式化开发方法为基础的变换模型（Transformational Model）。本节将简单地比较并分析瀑布模型、螺旋模型和变换模型等软件开发模型。1.2.1 瀑布模型瀑布模型即生存周期模型，其核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。采用瀑布模型的软件过程如图1-3所示。图1-3 采用瀑布模型的软件过程瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。瀑布模型的本质是一次通过，即每个活动只执行一次，最后得到软件产品，也称为“线性顺序模型”或者“传统生命周期”。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。瀑布模型有利于大型软件开发过程中人员的组织及管理，有利于软件开发方法和工具的研究与使用，从而提高了大型软件项目开发的质量和效率。然而软件开发的实践表明，上述各项活动之间并非完全是自上而下且呈线性图式的，因此瀑布模型存在严重的缺陷。 由于开发模型呈线性，所以当开发成果尚未经过测试时，用户无法看到软件的效果。这样软件与用户见面的时间间隔较长，也增加了一定的风险。 在软件开发前期末发现的错误传到后面的开发活动中时，可能会扩散，进而可能会造成整个软件项目开发失败。 在软件需求分析阶段，完全确定用户的所有需求是比较困难的，甚至可以说是不太可能的。1.2.2 螺旋模型螺旋模型将瀑布和演化模型（Evolution Model）结合起来，它不仅体现了两个模型的优点，而且还强调了其他模型均忽略了的风险分析。这种模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段，由这4个阶段进行迭代。软件开发过程每迭代一次，软件开发又前进一个层次。采用螺旋模型的软件过程如图1-4所示。图1-4 采用螺旋模型的软件过程螺旋模型基本做法是在“瀑布模型”的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制，它把软件项目分解成一个个小项目。每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应，因此特别适用于庞大、复杂并具有高风险的系统。对于这些系统，风险是软件开发不可忽视且潜在的不利因素，它可能在不同程度上损害软件开发过程，影响软件产品的质量。减小软件风险的目标是在造成危害之前，及时对风险进行识别及分析，决定采取何种对策，进而消除或减少风险的损害。与瀑布模型相比，螺旋模型支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供了方便，有助于提高目标软件的适应能力。并且为项目管理人员及时调整管理决策提供了便利，从而降低了软件开发风险。但是，我们不能说螺旋模型绝对比其他模型优越，事实上，这种模型也有其自身的如下缺点。 采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失。 过多的迭代次数会增加开发成本，延迟提交时间。1.2.3 变换模型变换模型是基于形式化规格说明语言及程序变换的软件开发模型，它采用形式化的软件开发方法对形式化的软件规格说明进行一系列自动或半自动的程序变换，最后映射为计算机系统能够接受的程序系统。采用变换模型的软件过程如图1-5所示。图1-5 采用变换模型的软件过程为了确认形式化规格说明与软件需求的一致性，往往以形式化规格说明为基础开发一个软件原型，用户可以从人机界面、系统主要功能和性能等几个方面对原型进行评审。必要时，可以修改软件需求、形式化规格说明和原型，直至原型被确认为止。这时软件开发人员即可对形式化的规格说明进行一系列的程序变换，直至生成计算机系统可以接受的目标代码。“程序变换”是软件开发的另一种方法，其基本思想是把程序设计的过程分为生成阶段和改进阶段。首先通过对问题的分析制定形式规范并生成一个程序，通常是一种函数型的“递归方程”。然后通过一系列保持正确性的源程序到源程序的变换，把函数型风格转换成过程型风格并进行数据结构和算法的求精，最终得到一个有效的面向过程的程序。这种变换过程是一种严格的形式推导过程，所以只需对变换前的程序的规范加以验证，变换后的程序的正确性将由变换法则的正确性来保证。变换模型的优点是解决了代码结构经多次修改而变坏的问题，减少了许多中间步骤（如设计、编码和测试等）。但是变换模型仍有较大局限，以形式化开发方法为基础的变换模型需要严格的数学理论和一整套开发环境的支持，目前形式化开发方法在理论、实践和人员培训方面距工程应用尚有一段距离。1.2.4 喷泉模型喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。该模型认为软件开发过程自下而上周期的各阶段是相互重叠和多次反复的，就像水喷上去又可以落下来，类似一个喷泉。各个开发阶段没有特定的次序要求，并且可以交互进行，可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏。采用喷泉模型的软件过程如图1-6所示。图1-6 采用喷泉模型的软件过程喷泉模型主要用于面向对象的软件项目，软件的某个部分通常被重复多次，相关对象在每次迭代中随之加入渐进的软件成分。各活动之间无明显边界，例如设计和实现之间没有明显的边界，这也称为“喷泉模型的无间隙性”。由于对象概念的引入，表达分析、设计及实现等活动只用对象类和关系，从而可以较容易地实现活动的迭代和无间隙。喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。1.2.5 智能模型智能模型也称为“基于知识的软件开发模型”，它把瀑布模型和专家系统结合在一起，利用专家系统来帮助软件开发人员的工作。该模型应用基于规则的系统，采用归纳和推理机制，使维护在系统规格说明一级进行。这种模型在实施过程中以软件工程知识为基础的生成规则构成的知识系统与包含应用领域知识规则的专家系统相结合，构成这一应用领域软件的开发系统。采用智能模型的软件过程如图1-7所示。图1-7 采用智能模型的软件过程智能模型所要解决的问题是特定领域的复杂问题，涉及大量的专业知识，而开发人员一般不是该领域的专家，他们对特定领域的熟悉需要一个过程，所以软件需求在初始阶段很难定义得很完整。因此，采用原型实现模型需要通过多次迭代来精化软件需求。智能模型以知识作为处理对象，这些知识既有理论知识，也有特定领域的经验。在开发过程中需要将这些知识从书本中和特定领域的知识库中抽取出来（即知识获取），选择适当的方法进行编码（即知识表示）建立知识库。将模型、软件工程知识与特定领域的知识分别存入数据库，在这个过程中需要系统开发人员与领域专家的密切合作。智能模型开发的软件系统强调数据的含义，并试图使用现实世界的语言表达数据的含义。该模型可以勘探现有的数据，从中发现新的事实方法指导用户以专家的水平解决复杂的问题。它以瀑布模型为基本框架，在不同开发阶段引入了原型实现方法和面向对象技术以克服瀑布模型的缺点，适应于特定领域软件和专家决策系统的开发。1.2.6 增量模型增量模型融合了瀑布模型的基本成分（重复应用）和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时，第1个增量往往是核心的产品，即第1个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。采用增量模型的软件过程如图1-8所示。增量模型与原型实现模型和其他演化方法一样，本质上是迭代的，但与原型实现不一样的是其强调每一个增量均发布一个可操作产品。早期的增量是最终产品的“可拆卸”版本，但提供了为用户服务的功能，并且为用户提供了评估的平台。增量模型的特点是引进了增量包的概念，无须等到所有需求都出来，只要某个需求的增量包出来即可进行开发。虽然某个增量包可能还需要进一步适应客户的需求并且更改，但只要这个增量包足够小，其影响对整个项目来说是可以承受的。图1-8 采用增量模型的软件过程采用增量模型的优点是人员分配灵活，刚开始不用投入大量人力资源。如果核心产品很受欢迎，则可增加人力实现下一个增量。当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径。这样即可先发布部分功能给客户，对客户起到镇静剂的作用。此外，增量能够有计划地管理技术风险。增量模型的缺点是如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。1.2.7 WINWIN模型WINWIN模型融合了螺旋模型的基本成分和原型实现的迭代特征，强调风险分析和标识。通过早期谈判使客户和开发者之间达成一致协议，它将变成进展到软件和系统定义的关键标准。WINWIN模型引入了3个里程碑，称为“抛锚点”。它可帮助建立一个生命周期的完全性，并提供在软件项目向前进展前的决策里程碑。采用WINWIN模型的软件过程如图1-9所示。图1-9 采用WINWIN模型的软件过程本质上，抛锚点表示了项目遍历螺旋时的3个不同的进展视图，第1个抛锚点称为“生存周期目标”，定义了一组针对每个主要软件工程活动的目标；第2个抛锚点称为“生存周期体系结构”，建立了当系统和软件体系结构被定义时必须满足的目标；第3个抛锚点称为“初始操作能力”，它表示一组目标，这些目标和将要安装销售软件的安装前场地准备和将使用该软件的各方所需的帮助相关联。WINWIN模型强调风险分析和标识，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应。采用WINWIN模型的优点是客户和开发者达到一种平衡，实现双赢，但是需要额外的谈判技巧。螺旋模型提出了强调客户交流的一个框架活动，该活动的目标是从客户处诱导出项目需求。在理想情况下，开发人员简单地询问客户需要什么，而客户提供足够的细节进行下去，不幸的是这种情形很少发生。而在WINWIN模型中，客户和开发人员进入一个谈判过程，客户被要求在成本和应市之间的约束下平衡功能、性能和其他产品或系统特征。最好的谈判追求“双赢”结果，即通过谈判客户获得大部分系统的功能，而开发人员则获得现实和可达到的预算和时限。1.2.8 原型实现模型原型实现模型从需求收集开始，开发者和客户在一起定义软件的总体目标，标识出已知的需求，并规划出需要进一步定义的区域。然后是“快速设计”，即集中于软件中那些对用户客户可见的部分的表示。这将导致原型的创建，并由用户客户评估并进一步精化待开发软件的需求。逐步调整原型使其满足客户的要求，而同时也使开发者对将要做的事情有更好的理解。这个过程是迭代的，其流程从听取客户意见开始，随后是建造修改原型、客户测试运行原型。然后往复循环，直到客户对原型满意为止。采用原型实现模型的软件过程如图1-10所示。图1-10 采用原型实现模型的软件过程原型实现模型的最大特点是能够快速实现一个可实际运行的系统初步模型，供开发人员和用户进行交流和评审，以便较准确地获得用户的需求。该模型采用逐步求精方法使原型逐步完善，即每次经用户评审后修改、运行，不断重复得到双方认可。这个过程是迭代过程，它可以避免在瀑布模型冗长的开发过程中看不见产品雏形的现象。其优点一是开发工具先进，开发效率高，使总的开发费用降低，时间缩短；二是开发人员与用户交流直观，可以澄清模糊需求，调动用户的积极参与，能及早暴露系统实施后潜在的一些问题；三是原型系统可作为培训环境，有利于用户培训和开发同步，开发过程也是学习过程。原型实现模型的缺点是产品原型在一定程度上限制了开发人员的创新，没有考虑软件的整体质量和长期的可维护性。由于达不到质量要求产品可能被抛弃，而采用新的模型重新设计，因此原型实现模型不适合嵌入式、实时控制及科学数值计算等大型软件系统的开发。增量模型和原型模型都是从概要需求出发开发的，但二者有明显不同。增量模型是从一些不完整的系统需求出发开始开发，在开发过程中逐渐发现新的需求。然后进一步充实完善该系统，使之成为实际可用的系统；原型开发的目的是为了发现并建立一个完整并经过证实的需求规格说明，然后以此作为正式系统的开发基础。因此原型开发阶段的输出是需求规格说明，这是为了降低整个软件生成期的费用而拉大需求分析阶段的一种方法，大部分原型是“用完就扔”的类型。1.2.9 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只能用于信息系统开发，不适合技术风险很高的情况。当一个新应用要采用很多新技术或当新软件要求与已有的计算机程序的高互操作性时，这种情况就会发生。1.2.10 并发开发模型并发开发模型也称为“并发工程”，它关注于多个任务的并发执行，表示为一系列的主要技术活动、任务及其相关状态。并发过程模型由客户要求、管理决策，评审结果驱动，不是将软件工程活动限定为一个顺序的事件序列，而是定义一个活动网络，网络上的每一个活动均可与其他活动同时发生。这种模型可以提供一个项目的当前状态的准确视图。采用并发开发模型的软件过程中一个活动的示意如图1-12所示。图1-12 并发过程模型的一个活动并发过程模型定义了一系列事件，对于每一个软件工程活动，它们触发一个状态到另一个状态的变迁。当它应用于客户机服务器系统时，并发过程模型在两维上定义活动，即一个系统维和一个构件维。其并发性通过如下两种方式得到。 系统维和构件维活动同时发生，并可以使用面向状态的方法进行建模。 一个典型的客户服务器应用通过多个构件实现，其中每个构件均可以并发设计并实现。并发开发模型试图根据传统生命周期的主要阶段来追踪项目的状态，项目管理者根本不可能了解项目的状态，因而需要使用比较简单的模型来追踪非常复杂的项目活动。并发开发模型使用状态图（表示一个加工状态）来表示与一个特定事件（如在开发后期需求的一个修改）相关的活动之间存在的并发关系，但它不能捕获到贯穿于一个项目中所有软件开发和管理活动的大量并发。大多数软件开发过程模型均为时间驱动，越到模型的后端，就越到开发过程的后一阶段，而一个并发过程模型是由用户要求、管理决策和结果复审驱动的。并发开发模型在软件开发全过程活动的并行化，打破了传统软件开发的各阶段分割封闭的观念。强调开发人员团队协作，注重分析和设计等前段开发工作，从而避免了不必要的返工。其优点是可用于所有类型的软件开发，而对于客户服务器结构更加有效，可以随时查阅到开发的状态。1.2.11 基于构件的开发模型基于构件的开发模型利用模块化方法将整个系统模块化，并在一定构件模型的支持下复用构件库中的一个或多个软件构件，通过组合手段高效率、高质量地构造应用软件系统的过程。基于构件的开发模型融合了螺旋模型的许多特征，本质上是演化形的，开发过程是迭代的。基于构件的开发模型由软件的需求分析和定义、体系结构设计、构件库建立、应用软件构建，以及测试和发布5个阶段组成，采用这种开发模型的软件过程如图1-13所示。图1-13 采用基于构件的开发模型的软件过程构件作为重要的软件技术和工具得到极大的发展，这些新技术和工具有Microsoft的DCOM、Sun的EJB，以及OMG的CORBA等。基于构件的开发活动从标识候选构件开始，通过搜查已有构件库，确认所需要的构件是否已经存在。如果已经存在，则从构件库中提取出来复用；否则采用面向对象方法开发它。之后利用提取出来的构件通过语法和语义检查后将这些构件通过胶合代码组装到一起实现系统，这个过程是迭代的。基于构件的开发方法使得软件开发不再一切从头开发，开发的过程就是构件组装的过程，维护的过程就是构件升级、替换和扩充的过程。其优点是构件组装模型导致了软件的复用，提高了软件开发的效率。构件可由一方定义其规格说明，被另一方实现。然后供给第三方使用，构件组装模型允许多个项目同时开发，降低了费用，提高了可维护性，可实现分步提交软件产品。由于采用自定义的组装结构标准，缺乏通用的组装结构标准，因而引入了较大的风险。可重用性和软件高效性不易协调，需要精干的有经验的分析和开发人员，一般开发人员插不上手。客户的满意度低，并且由于过分依赖于构件，所以构件库的质量影响着产品质量。1.2.12 基于体系结构的开发模型基于体系结构的开发模型是以软件体系结构为核心，以基于构件的开发方法为基础。然后采用迭代增量方式进行分析和设计，将功能设计空间映射到结构设计空间，再由结构设计空间映射到系统设计空间的过程。该开发模型把软件生命周期分为软件定义、需求分析和定义、体系结构设计、软件系统设计和软件实现5个阶段，采用这种开发模型的软件过程如图1-14所示。图1-14 采用基于体系结构的开发模型的软件过程在基于体系结构的开发过程中，首先是基于体系结构的需求获取和分析，将软件体系结构的概念引入到需求空间，从而为分析阶段到设计阶段的过渡提供更好的支持。在需求分析结果的基础上，进行体系结构的设计。考虑系统的总体结构及系统的构成元素，根据构成元素的语法和语义在已确定的构件库中寻找匹配的构件。当不存在符合要求的构件时，则根据具体情况组装合成新构件或者购买新构件或者根据需要开发新构件而得到满足需求的构件。在经过语法和语义检查后，将这些构件通过胶合代码组装到一起实现整个软件系统。在实践中，整个开发过程呈现多次迭代性。在传统的软件生命周期中，软件需求分析和定义完成后紧接的是软件系统的设计和实现。在这种传统的开发方法中，如果软件需求不断变化，最终软件产品可能与初始原型相差很大。而基于体系结构的开发模型有严格的理论基础和工程原则，是以体系结构为核心。体系结构为软件需求与软件设计之间架起了一座桥梁，解决了软件系统从需求到实现的平缓过渡，提高了软件分析设计的质量和效率。基于体系结构的开发模型的优点是通过对体系结构的设计，使得软件系统结构框架更清晰，有利于系统的设计、开发和维护，并且软件复用从代码级的复用提升到构件和体系结构级的复用。基于体系结构的开发模型和基于构件的开发模型都是在体系结构的基础上进行构件的组装而得到软件系统，前者主要关注运行级构件及其之间的互操作性，提供了一种自底向上且基于预先定制好的构件来构造应用系统的途径；后者局限在构件的规范上，缺少系统化的指导开发过程的方法学。基于体系结构的开发方法从系统的总体结构入手，将一个系统的体系结构显示化，以在高抽象层次处理诸如全局组织和控制结构、功能到计算元素的分配、计算元素间的高层交互等设计问题。1.2.13 XP方法敏捷方法是近几年兴起的一种轻量级的开发方法，它强调适应性而非预测性、强调以人为中心，而不以流程为中心，以及对变化的适应和对人性的关注，其特点是轻载、基于时间、Just Enough、并行并基于构件的软件过程。在所有的敏捷方法中，XP（eXtreme Programming）方法是最引人注目的一种轻型开发方法。它规定了一组核心价值和方法，消除了大多数重量型过程的不必要产物，建立了一个渐进型开发过程。该方法将开发阶段的4个活动（分析、设计、编码和测试）混合在一起，在全过程中采用迭代增量开发、反馈修正和反复测试。它把软件生命周期划分为用户故事、体系结构、发布计划、交互、接受测试和小型发布6个阶段，采用这种开发模型的软件过程如图1-15所示。图1-15 采用XP方法的软件过程XP模型通过对传统软件开发的标准方法进行重新审视，提出了由一组规则组成的一些简便易行的过程。由于这些规则是通过在实践中观察使软件高效或缓慢的因素而得出的，因此它既考虑了保持开发人员的活力和创造性，又考虑了开发过程的有组织、有重点和持续性。XP模型是面向客户的开发模型，重点强调用户的满意程度。开发过程中对需求改变的适应能力较高，即使在开发的后期，也可较高程度地适应用户的改变。XP开发模型与传统模型相比具有很大的不同，其核心思想是交流（Communication）、简单（Simplicity）、反馈（Feedback）和进取（Aggressiveness）。XP开发小组不仅包括开发人员，还包括管理人员和客户。该模型强调小组内成员之间要经常进行交流，在尽量保证质量可以运行的前提下力求过程和代码的简单化；来自客户、开发人员和最终用户的具体反馈意见可以提供更多的机会来调整设计，保证把握正确的开发方向；进取则包含于上述3个原则中。XP开发方法中有许多新思路，如采用“用户故事”代替传统模型中的需求分析，“用户故事”由用户用自己领域中的词汇并且不考虑任何技术细节准确地表达自己的需求。XP模型的优点如下。 采用简单计划策略，不需要长期计划和复杂模型，开发周期短。 在全过程采用迭代增量开发、反馈修正和反复测试的方法，软件质量有保证。 能够适应用户经常变化的需求，提供用户满意的高质量软件。1.2.14 第4代技术第4代技术（4GT）包含一系列软件工具，它们都具有一个共同点，即能使软件工程师在较高级别上规约软件的某些特征，然后根据开发者的规约自动生成源代码。毫无疑问，软件在越高级别上被规约就能越快速地构造出程序。软件工程的第4代技术模型集中于规约软件的能力，即使用特殊的语言形式或一种采用客户可以理解的术语描述待解决问题的图形符号体系。与其他模型一样，第4代技术也是从需求收集开始的。理想情况下，客户能够描述出需求，而这些需求能被直接转换成可操作原型。但这是不现实的，客户可能不能完全确定需要什么，在规约已知的事实时可能出现二义性，因此其他模型中所描述的用户开发者对话在第4代技术中仍然是一个必要的组成部分。要将一个第4代技术实现变成最终产品，开发人员还必须进行彻底的测试、开发有意义的文档，并且同样要完成其他模型中同样要求的所有集成活动。此外，采用第4代技术开发的软件还必须使得维护能够被迅速完成的方式建造。与其他所有软件过程模型一样，第4代技术模型也有其优点和缺点。其优点是缩短了软件开发时间，提高了建造软件的效率并为很多不同的应用领域提供了一种可行性途径和解决方案；其缺点是用工具生成的源代码可能是“低效”的，生成的大型软件的可维护性目前还令人怀疑并且在某些情况下可能需要更多的时间。总之，第4代技术已经成为软件工程的一个重要方法。当与基于构件的开发方法结合起来后，可能成为软件开发的主流方法。1.2.15 小结软件工程是集成计算机软件开发的过程、方法和工具的学科，已经产生的一系列的软件工程过程模型各自有其优点和缺点，但是它们均有一系列共同的一般阶段。软件过程模型发展经历了以下阶段。 以软件需求完全确定为前提的第1代软件过程模型，如瀑布模型等。这类开发模型的特点是软件需求在开发阶段已经被完全确定，将生命周期的各项活动依顺序固定，强调开发的阶段性；其缺点是开发后期要改正早期存在的问题需要付出很高的代价，用户需要等待较长时间才能够看到软件产品，增加了风险系数。并且如果在开发过程存在阻塞问题，则影响开发效率。 在开始阶段只能提供基本需求的渐进式开发模型，如螺旋模型和原型实现模型等。这类开发模型的特点是软件开发开始阶段只有基本的需求，软件开发过程的各个活动是迭代的。通过迭代过程实现软件的逐步演化，最终得到软件产品。在此引入了风险管理，采取早期预防措施，增加项目成功几率，提高软件质量；其缺点是由于需求的不完全性，从而为软件的总体设计带来了困难和削弱了产品设计的完整性，并要求对风险技能管理水平的高要求。 以体系结构为基础的基于构件组装的开发模型，如基于构件的开发模型和基于体系结构的开发模型等。这类模型的特点是利用需求分析结果设计出软件的总体结构，通过基于构件的组装方法来构造软件系统。软件体系结构的出现使得软件的结构框架更清晰，有利于系统的设计、开发和维护。综上所述，软件开发模型随着软件设计思想的改变而发展，经历了由最初以结构化程序设计思想为指导的瀑布模型等，到以面向对象思想为指导的喷泉模型等，到以构件开发思想为指导的基于体系结构的开发模型等，到现在的4GT技术。每次新的软件设计思想的突破都会出现新的软件开发过程模型，以达到提高软件的生产效率和质量为目标，提出新的解决“软件危机”问题的方案。软件开发模型面面观在实际的软件开发中，很少有某个开发团队完全遵循开发模型的规定，因为每个模型都有其限定条件，并不完全适用于所有的开发环境。 软件开发模型又称软件生命周期模型，它制定了一系列的步骤或活动，软件开发人员或开发团队需要在开发中按照软件模型中指定的步骤来进行软件开发。但实际上，很少有某个开发团队完全遵循开发模型的规定，这是因为每个模型都会有一定的限定条件和应用范围，并不是完全适用于所有的开发环境。 在整个开发过程中，收集的数据基本上体现了“三边”（边想，边做，边改）的软件开发模式应用。在该模型中不使用规格说明书（它明确地说明了系统的功能需求，从技术角度定义了我们需要做什么）。同时该模型也不尝试去设计一个软件，仅仅是将所有的软件构思全部用代码表述，软件的设计和编程思路完全维持在程序员的头脑中。显然，它不适用于小组开发，同时也不便于维护。因为，我们无法从程序员的头脑中“抓出”对于软件的任何准确的描述。 下面探讨一些比较经典的和近来比较风靡的开发模型，同时说明它们的使用范围和特点。 瀑布模型 为了使软件工程便于协作开发和易于维护，在自动化时代一种较为有效的模型被开发团队广泛接受，那就是瀑布模型。 瀑布模型一般由“需求阶段”、“规格说明阶段”、“设计阶段”、“实现阶段”、“集成阶段”、和“推广阶段”组成。为了全面分析各个模型的特点，下面简要地介绍该模型的每个阶段： 在需求阶段，由系统分析师来确定整个系统的功能需求和非功能需求（如“可靠性和可维护性”等特性），然后由客户和一个软件质量保证组（Software Quality Assurance，SQA）与客户一同确定需求。实际需求阶段包含两个活动，需求分析与需求获取。 在需求获得认可后需要由同一小组建立规格说明文档，以文字的方式说明系统要做些什么。最终该文档需要获得客户的认可，同时客户将以该文档的内容来验收项目。当然，在该阶段完成后就可以指定软件项目管理计划，来规定开发中的每个活动和成果、所需的资源、时间、成本等。 接下来，系统工程师将会在明确技术规格说明书后，建立模块和它们的关联，从而构成系统的结构设计。系统的结构设计完成后，某些时候会对每个模块选定一个算法和详细的数据结果，这是从一个单一的模块角度来进行考虑的。当完成设计后，还需要对设计进行测试，一般来说是通过对设计的人为审查来完成。 当设计的说明交给程序员时，开发进入实现阶段，由程序员负责每个模块程序的编写和测试，确保程序的测试结果与设计说明中所描述的一致。 当所有的程序编写完成后，将进入集成阶段，也就是以产品或系统的角度对所有模块进行系统级别的测试。这里主要的工作就是对程序进行测试，所以该阶段需要编写详细的测试文档。 一旦客户接受了产品，任何修改（无论是完善性维护还是纠错性维护）都会被视为维护阶段。这里需要指明的是维护的顺序，可能有些维护需要回溯到设计阶段，甚至是技术规格说明书阶段或需求阶段。 瀑布模型的优点显而易见，线性的开发结构使它更加便于管理。瀑布模型适应于自动化项目，因为那时的功能需求可以从范围和业务流程中准确识别；但是，对于其他类型项目，瀑布模型的结构将会产生致命的缺陷，即客户在项目初期的需求不明确性导致开发出的产品并不是客户所需要的。 快速原型开发模型 “快速原型”是一个与产品子集功能上相同的工作模型。例如，目标产品是处理账务的财会软件，那么快速原型则需要建立对应功能是交互的界面和打印的报表。 快速原型与瀑布模型基本上是一致的。它的第一步是建造一个快速原型，来代替需求阶段的需求分析和获取。客户和未来的用户可以使用该快速原型，同时可以提出反馈，然后程序员进一步修改快速原型，客户再进行确认，直到捕捉到客户所有的功能需求为止，也就是客户认为这个快速原型满足了它的大多数要求为止。 一旦确定了客户的需求，就会进入技术规格说明阶段，制定详细的规格说明书，以便系统设计师来设计系统。 快速原型的引入主要是为了确立明确的功能需求而设。它的主要构思是通过一个简单的原型，从系统的角度引出和明确客户的期盼和愿望。当然它可以使客户在第一时间了解到系统的功能到底是如何运作的，但是在信息化时代，该方法显然并不理想。 比如对于一个无法明确表明的“功能”，我们如何建立该原型？我们到底从何而知，在什么时候由客户确认的原型是系统所能体现的主要功能？我们从何而知该项目的范围？我们又从何而知项目的工作计划到底应当如何制定出里程碑呢？ 显然，很多问题困扰着快速原型的开发，在今天的信息化项目中尤其突出。 增量和演化开发模型 软件是建造出来的，而不是写出来的。根据这个思想，增量模型被设计出来，它主要强调的是每一步软件的开发都建立在前一步软件开发的基础之上。 增量模型将会分阶段交付产品，以满足客户需求的每一个子集。所以，整个系统备份按若干个构件逐个交付产品，在每个阶段客户都会得到一个满足了他们某一部分需求的产品，同时他们可以在其他产品没有构建出来时，就初步了解到该构件的使用方法。 增量模型的优点是减少了客户对于新产品的适应度、客户可以分批地为每个构件付款（有利于客户的资金周转）。但是，增量模型的问题也是显著的，即如何组织一个开放的结构才能使该模型不会退化到建造修补模型。 与增量模型相对应的是演化模型，它强调的是增量和迭代两个特征的结合。演化模型的目标是克服瀑布模型中线性开发带出交付上的风险，即只有到了最终交付时才获知哪部分产品需要维护，这会使得整个项目的开发成本和时间远远超出预支。由于在维护阶段修改软件的费用要远远大于在需求或设计阶段修改软件的费用，所以演化模型使用了迭代和增量的思想，将整个软件的开发风险分散到不同构建的不同阶段。 演化模型的主要步骤是首先开发出系统的一个核心功能，使得客户可以与开发人员一同确认该功能，这样开发人员将会得到第一手的经验，再根据客户的反馈进一步开发出其他功能或进一步扩充该功能，从而建立一个完整的系统位置。 每一次开发都会涉及“风险分析”、“原型建立”、“实现原型”、“评估原型”，这就构成多次迭代来完成整个系统的开发。 演化模型的特点基本上与增量模型一致，但是对于演化模型的管理是一个主要的阻力，也就是说，我们很难确认整个系统的里程碑、成本和时间基线。 统一过程模型 下面介绍的是近期在业界比较风靡的两个主要的开发模型，对于它们的应用效果，由于各种原因，我们不给出具体的评估，仅仅是从使用角度进行简单分析（或者提出一些疑问）。 为了利用从上述模型成功和失败的历史中学到的一些有益于软件工程的知识，统一过程模型寻求了一种方法来改进原有的过程，包括瀑布模型、演化模型等。也就是说，统一过程融入了瀑布模型的线性结构和演化模型的增量和迭代思想。 统一过程首先建立了整个项目的不同阶段，包括“初始阶段”、“细化阶段”、“构造阶段”、“移交阶段”。同时每个阶段中又保留了瀑布模型的活动，这里称之为工作流，即从需求、分析到设计和实现、测试这五个活动。所以，我们可以将其理解为一个二维坐标，工作流是一个竖坐标，阶段构成了横坐标。但是，二维坐标并不是统一过程的主要思想，它的主要思想是每个竖坐标制定的活动可能会产生多次迭代，每个迭代会随着横坐标（阶段）的进展而产生变更，最终逐渐减少直至消失。 每个阶段都能构成一个里程碑，在每个里程碑上可以捕捉到软件项目生命周期中的重要决策点。如初始阶段关注的是项目计划和风险评估，细化阶段关注的是系统的总体构架，构造阶段则关注建立系统等。 正如我们开始所说的，我们并不准备对该模型进行评价。这里仅仅是提出一些问题供大家思考。首先，我们如何知道每个里程碑的制定点？其次，如何确立我们建立了完整的功能需求？再次，每个阶段中到底要包含多少个迭代（阶段中的子阶段）？最后，如何维护在每次迭代中需求、设计、代码等的一致性？ 业务构件开发模型 业务构件开发其实并不属于软件开发模型，它仅仅是一个利用业务角度来架构整个系统的手段（没有使用“方法”一词，主要是与开发模型中的方法系进行区别，以免造成歧义）。 实际上，面向业务构建整个系统是需要一个完善的开发模型来说明它是如何运作的，这也是本书的主题之一。所以，在这里仅仅介绍当前较为流行的主要架构的特征。 现在最为主要的有两种，一是以服务角度（服务构件）来建立系统架构，二是以业务流程角度建立系统架构。但是，实际上它们讨论的都是同一件事情，即先确立业务流程，再以服务为单元架构系统。 那么，这些方法是否可行呢？实践证明他们是可行的，但是效果并不十分理想（不要忘记今天项目的70%的失败率）。我们也不准备分析它们的优缺点，仅仅想指出在使用它们时读者应当考虑的问题。比如，如何知道一个业务流程是客户所需的？如何缩短建立业务流程的时间和提高每个流程的明确度（任务明确）？如何确立不同业务构建之间的架构是合理的？如何确立一个业务构件是必需的？ 信息化项目中的模型应用分析 在对这些模型进一步剖析前，我们有必要再回顾一下我们的艰难历程，来判断在信息时代我们是否使用上述的软件过程就可以达到那些模型所承诺的目标呢？ 瀑布模型在信息化时代已经很难取得在自动化时代的成功了。因为，我们很难再像自动化时代那样，通过一个业务流程来确立系统的功能需求，那样规格说明书和设计就会显得苍白无力。反之，规格说明书和设计反而使得系统的构建更加复杂，因为任何需求的变更都会或多或少地损害系统的模块划分和系统架构，那么试想，对于一个10万行代码的项目而言，如果需求的变更致使设计阶段的成果超过一半都产生了变更，那么至少这种开发模型已不再是瀑布模型。因为瀑布模型的特点就是稳固的近似线性结构的开发结构。 对于快速原型而言，信息化项目则是它的“阿喀琉斯之踵”。因为，信息化项目已不再是传统的自动化改善，而是由系统带出客户期盼的价值。那么，我们又如何建立一个原型让客户体验呢？ 试想，如果我们建立出和未来系统对应的一模一样的原型，那么我们希望客户告诉我们什么呢？这个系统是界面还是报表？这显然不可能。客户都不知道他们的业务操作流程是如何运转的，又如何告诉我们这些界面可提供什么呢？当然，原型法的目的是通过引导客户的需求来完善系统，但是我们又如何知道一个原型对于捕捉这些界面上的需求或报表的需求到底是否完整？无论是客户还是我们，都根本不知道我们在做什么，到底什么时候才使客户得到了满足。 演化过程显然更不会在信息化时代获得成功，如果我们先开发出系统的核心功能，再根据构建的功能进一步向“系统”挺进。那么，在客户和我们都不知道系统如何提供价值时，试问哪个功能才是核心功能呢？我们尚且不知道我们交付什么时，试问我们怎么知道需要多少次迭代才能构建出最终的系统呢？即使在最佳假设的情况下（假定客户决定了核心功能，虽然不知道多少次迭代，但是可以预估最大上限），系统的频繁变更会使得我们最终退化到建造修补模型。 那么现在风靡业界的统一过程又如何呢？我们不会具体分析该模型在信息化时代的效果如何。在这里，只想提出两个问题：范围从哪里建立？如何通过迭代来明确地说明在这次迭代中功能需求是否完整？ 下期黄教授将解答以上问题，明确这些过程的特征。 作者简介 黄绍良，中国管理科学研究院理事兼改革及发展研究所研究员，美国PMI项目管理专业资格认证委员会（PgMPCC）委员，国际创新管理专业协会（ISPIM）会员。 图1 瀑布模型 图2 快速原型开发模型 图3 增量模型 软件开发模型对比 软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。 软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。 最早出现的软件开发模型是1970年WRoyce提出的瀑布模型。该模型给出了固定的顺序，将生存期活动从上一个阶段向下一个阶段逐级过渡，如同流水下泻，最终得到所开发的软件产品，投入使用。但计算拓广到统计分析、商业事务等领域时，大多数程序采用高级语言(如FORTRAN、COBOL等)编写。瀑布模式模型也存在着缺乏灵活性、无法通过并发活动澄清本来不够确切的需求等缺点。 典型的开发模型有：瀑布模型(waterfall model)；渐增模型/演化/迭代(incremental model)；原型模型(prototype model)；螺旋模型(spiral model)；喷泉模型(fountain model)；智能模型(intelligent model) ; 7. 混合模型(hybrid model)1. 边做边改模型（Build-and-Fix Model）遗憾的是，许多产品都是使用边做边改模型来开发的。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改. 在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。 这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：（1） 缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；（2） 忽略需求环节，给软件开发带来很大的风险；（3） 没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。2. 瀑布模型（Waterfall Model） 1970年Winston Royce提出了著名的瀑布模型，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。 瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。 在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返