软件开发过程模型综述

目录

1、软件开发过程模型的含义

2、各种典型软件开发过程模型

---

1、软件开发过程模型的含义

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

（2）软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。

（3）对于不同的软件系统，可以采用不同的开发方法、使用不同的程序设计语言以及各种不同技能的人员参与工作、运用不同的管理方法和手段等，以及允许采用不同的软件工具和不同的软件工程环境。

（4）每个软件开发组织应该选择适合于该组织的软件开发模型，并且应该随着当前正在开发的特定产品特性而变化，以减小所选模型的缺点，充分利用其优点，常见模型有：1.边做边改模型（Build-and-Fix Model）；2.瀑布模型（Waterfall Model）；3.快速原型模型（Rapid Prototype Model）；4.增量模型（Incremental Model）；5.螺旋模型（Spiral Model）；6.演化模型(evolution model)；7.喷泉模型(fountain model)；8.智能模型(四代技术（4GL）)；9.混合模型（hybrid model）；10.RAD模型。

2、各种典型软件开发过程模型

（1）瀑布模型

·基本策略：将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

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

·产生背景：1970年Winston Royce提出了著名的"瀑布模型"，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。

·适用范围：在开发时间内需求没有或很少变化；分析设计人员应对应用领域很熟悉；低风险项目（对目标、环境很熟悉）；用户使用环境很稳定；用户除提出需求以外，很少参与开发工作。

·局限性：各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

（2）螺旋模型

·基本策略：螺旋模型（Spiral Model）采用一种周期性的方法来进行系统开发。这会导致开发出众多的中间版本。使用它，项目经理在早期就能够为客户实证某些概念。该模型是快速原型法，以进化的开发方式为中心，在每个项目阶段使用瀑布模型法。这种模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段，由这4个阶段进行迭代。软件开发过程每迭代一次，软件开发又前进一个层次。

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

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

·适用范围：螺旋模型只适合于大规模的软件项目。

·局限性：螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发；如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目；软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险。

（3）增量模型

·基本策略：又称演化模型。与建造大厦相同，软件也是一步一步建造起来的。在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。

·产生背景：增量模型融合了瀑布模型的基本成分（重复应用）和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。

·适用范围：进行已有产品升级或新版本开发，增量模型是非常适合的；对所开发的领域比较熟悉而且已有原型系统，增量模型也是非常适合的。

·局限性：由于各个构件是逐渐并入已有的软件中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构； 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。

（4）原型模型

·基本策略：原型模型指的是在执行实际软件的开发之前，应当建立系统的一个工作原型。一个原型通常是实际系统的一个比较粗糙的版本。

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

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

·局限性：原型的快速开发往往忽略了非功能方面的因素，如性能、健壮性和可靠性等；缺乏必要的开发文档，不利于后期维护。

（5）喷泉模型

·基本策略：该模型认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性。软件的某个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分。无间隙指在各项活动之间无明显边界，如分析和设计活动之间没有明显的界限，由于对象概念的引入，表达分析、设计、实现等活动只用对象类和关系，从而可以较为容易地实现活动的迭代和无间隙，使其开发自然地包括复用。

·产生背景：喷泉模型与传统的结构化生存期比较，具有更多的增量和迭代性质，生存期的各个阶段可以相互重叠和多次反复，而且在项目的整个生存期中还可以嵌入子生存期。

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

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

（6）RUP模型

RUP中的软件生命周期在时间上被分解为四个顺序的阶段，分别是：初始阶段（Inception）、细化阶段（Elaboration）、构造阶段（Construction）和交付阶段（Transition）。每个阶段结束于一个主要的里程碑（Major Milestones）；每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。

（1）初始阶段。初始阶段的目标是为系统建立商业案例并确定项目的边界。为了达到该目的必须识别所有与系统交互的外部实体，在较高层次上定义交互的特性。本阶段具有非常重要的意义，在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来讲，初始阶段可能很短。初始阶段结束时是第一个重要的里程碑：生命周期目标（Lifecycle Objective）里程碑。生命周期目标里程碑评价项目基本的生存能力。

（2）细化阶段。细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。为了达到该目的，必须在理解整个系统的基础上，对体系结构作出决策，包括其范围、主要功能和诸如性能等非功能需求。同时为项目建立支持环境，包括创建开发案例，创建模板、准则并准备工具。细化阶段结束时第二个重要的里程碑：生命周期结构（Lifecycle Architecture）里程碑。生命周期结构里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中进行衡量。此刻，要检验详细的系统目标和范围、结构的选择以及主要风险的解决方案。

（3）构造阶段。在构建阶段，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。从某种意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制运作以优化成本、进度和质量。构建阶段结束时是第三个重要的里程碑：初始功能（Initial Operational）里程碑。初始功能里程碑决定了产品是否可以在测试环境中进行部署。此刻，要确定软件、环境、用户是否可以开始系统的运作。此时的产品版本也常被称为“beta”版。

（4）交付阶段。交付阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量的调整。在生命周期的这一点上，用户反馈应主要集中在产品调整，设置、安装和可用性问题，所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。在交付阶段的终点是第四个里程碑：产品发布（Product Release）里程碑。此时，要确定目标是否实现，是否应该开始另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的结束重合。

（5）RUP中有9个核心工作流，分为6个核心过程工作流（Core Process Workflows）和3个核心支持工作流（Core Supporting Workflows）。尽管6个核心过程工作流可能使人想起传统瀑布模型中的几个阶段，但应注意迭代过程中的阶段是完全不同的，这些工作流在整个生命周期中一次又一次被访问。9个核心工作流在项目中轮流被使用，在每一次迭代中以不同的重点和强度重复。

（6）RUP的特点：

1、迭代式的增量开发

受控的迭代式增量开发

1）将软件开发分为一系列小的迭代过程，在每个得带过程中逐步增加信息、进行细化

2）根据具体情况决定迭代的次数、每次迭代延续的时间以及迭代工作流

3）每次迭代都选择目前对风险影响最大的用例进行，以分解和降低风险

2、用例（Use case-driven）驱动

1）采用用例来捕获对目标系统的功能需求

2）采用用例来驱动软件的整个开发过程，保证需求的可跟踪性，确保系统所有功能均被实现

3）将用户关心的软件系统的业务功能实体功能模型和开发人员结合起来，提供一种贯穿整体软件生存周期的开发方式，使得软件开发的各个阶段的工作自然、一致地协调起来

3、以软件体系结构为中心

1））强调在开发过程的早期，识别出软件与软件的体系结构紧密相关的用例，并通过对这些用例的分析、设计、实现和测试，形成体系结构框架；

2）在后续阶段中对已形成的体系结构框架进行不断细化，最终实现整体系统。

3）在开发过程中的早期形成良好的软件体系结构，有利于对系统的理解、支持重用和有效的组织软件开发。

（7）敏捷建模和极限编程

·模型概述：

一种以实践为基础的软件工程过程和思想。使用快速反馈测试（测试驱动）、大量而迅速的交流，经过保证的测试来最大限度的满足用户的需求。主要强调用户满意，开发人员可以对需求的变化作出快速的反应。

每个参加项目开发的人都将担任一个角色（项目经理、项目监督人等等）并履行相应的权利和义务。

·模型特点：

测试驱动：XP内层的过程基于Test Driven Development，每个开发周期都有很多相应的单元测试。

大力提倡设计复核（Review）、代码复核以及重整和优化（Refectory），这些过程也是优化设计的过程；

提倡配对编程（Pair Programming），而且代码所有权是归于整个开发队伍。

程序员在写程序和重整优化程序时要严格遵守编程规范。

任何人可以修改其他人写的程序，但修改后要确定新程序能通过单元测试。

在开始写程序之前先写单元测试。