15种软件过程经典模型及各自适用范围、优缺点

目录

一、线形顺序模型系列

1.1 线性顺序模型(不推荐)

1.2 瀑布模型(不推荐)

1.3 V模型(不推荐)

1.4 国防部DoD模型(不推荐)

1.5 循环(圆形)模型(不推荐)

1.6 RAD模型

二、 演进模型系列

2.1 原型模型

2.2 边建(做)边改

2.3 增量模型(推荐)

2.4 螺旋模型(推荐)

2.5 并发模型

2.6 XP模型(推荐)

2.7 RUP模型(推荐)

三、 其他模型系列

3.1 构建组装CBD模型

3.2 形式化方法模型

3.3 IDEAL模型

四、参考文献

---

一、线形顺序模型系列

1.1 线性顺序模型(不推荐)

软件工程的线性顺序模型，有时也称“传统生命周期”或“瀑布模型”，线性顺序模型提出了软件开发的系统化的、顺序的方法（虽然由Winston Royce[ROY70]提出的最早的瀑布模型支持带有反馈的循环，但大多数使用该过程模型的组织均把它视为是严格线性的）。

这也是线性顺序模型和瀑布模型的不同之处，一个不带反馈，一个带反馈。

使用特点：

1）阶段间具备高度的顺序性和依赖性，项目从开始到结束按照一定的顺序执行；线性顺序模型是文档驱动的，各个阶段不连续也不交叉。

2）严格阶段评估，必须先进行一个阶段严格评估才能进入下一个阶段。

3）开发初期需要清楚全部需求。

4）开发周期长，风险大。

优点：

1）作为最早期的软件过程模型，它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

2）尽管有不少缺陷，但比在软件开发中呈现随意的状态要好得多。

缺点： 

1）实际的项目大部分情况难以按照该模型给出的顺序进行，而且这种模型的迭代是间接的，这很容易由微小的变化而造成大的混乱。

2）很多情况下客户难以表达真正的需求，而这种模型却要求如此，这种模型是不“欢迎”具有二义性问题存在的。

3）客户要等到开发周期的末期才能看到程序运行的测试版本，而在这时发现大的错误时，可能引起客户的惊慌，而造成的后果也可能是灾难性的。

4）经常会在过程的开始和结束时碰到等待其他成员完成其所依赖的任务才能进行下去的情况，有可能花在等待的时间比开发的时间要长，称为“堵塞状态”。

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

1.2 瀑布模型(不推荐)

瀑布模型（Waterfall Model） 是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。

使用特点：

1）对于经常变化的项目而言，瀑布模型毫无价值。

2）适用于需求明确的项目，一般表述为需求明确、或二次开发，或者对于数据处理类型的项目。

3）瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。

4）由于瀑布模型几乎完全依赖于书面的规格说明，可能导致开发出的软件产品不能真正满足用户的需要。

优点：

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

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

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

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

4）它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

缺点：

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

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

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

4）瀑布模型的突出缺点是不适应用户需求的变化。

5）在软件开发的初始阶段指明软件系统的全部需求是困难的，有时甚至是不现实的。而瀑布模型在需求分析阶段要求客户和系统分析员必须做到这一点才能开展后续阶段的工作。
6）确定需求后，用户和软件项目负责人要等相当长的时间才能得到一份软件的最初版本。如果用户对这个软件提出比较大的修改意见，那么整个软件项目将会蒙受巨大的人力、财力和时间方面的损失。

1.3 V模型(不推荐)

V模型（V-model），瀑布模型的一个变体，强调在各个阶段进行测试和验证，以提升软件质量。由于其模型构图形似字母V，所以又称软件测试的V模型。

使用特点：

1）V模式是一种传统软件开发模型，一般适用于一些传统信息系统应用的开发，而一些高性能高风险的系统、互联网软件，或一个系统难以被具体模块化的时候，就比较难做成V模式所需的各种构件，需要更强调迭代的开发模型或者敏捷开发模型。

2）V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。

3）V模型架构是能够用于任何项目管理或系统开发方法的结构性的测试方法

4）该方法从项目开展到项目终结，无时无刻不强调质量控制。

优点：

1）既有底层测试又有高层测试。底层：单元测试。高层：系统测试。

2）V模型是瀑布模型的一种加强，可以提升软件质量，但也更消耗人力和时间。

缺点：

1）模型的局限性是仅把测试过程作为需求分析、概要设计、详细设计以及编码后的一个阶段。容易使人理解为测试是软件开发的最后一个阶段，主要针对程序进行寻错的活动，而忽略了测试活动对需求分析、系统设计等活动的验证和确认的功能。

2）V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，需求的满足情况一直到后期的验收测试才被验证。

1.4 国防部DoD模型(不推荐)

由于历史的原因，美国军方早期制定了不少的软件工程标准，著名标准有MIL-STD-2167A,DoD-STD-498,MIL-STD-1703,但随着国际标准和其他组织的标准日趋完善和成熟，美国军方基本不再制定软件工程标准，而直接采用国际标准。美国军方明确表示将采用ISO/IEC 12207。目前美国军方所关注的最重要的事实标准就是CMM：软件能力成熟度模型集成。

DoD模型描述了与硬件相关联的活动，而这些活动又与跟软件相关联的活动相互独立。在项目进入最后的系统集成过程以前，这两个关键的路径能够且应该分开管理，这种错误结论导致了许多项目的失败。这个模型使用了几十年，但在20世纪90年代中期，当DoD开始指导它的员工和承包商采用软件开发的商业标准时被放弃。

1.5 循环(圆形)模型(不推荐)

将辅助性活动放入到过程模型中。问题主要有两个方面：
1．将连续存在的活动错误地认为是按照顺序排列的活动：将“风险分析和管理”这种连续存在的情形活动错误地认为是顺序活动；将“配置管理”和“技术疏忽”这些连续过程错误地表示为按照顺序排列的活动。
2．某些活动放置的位置不合理：
“概念开发”的位置放置有问题，应该在1号活动之后立刻进行“实施计划和系统集成”活动的放置位置也有问题，应该在项目周期的早期进行计划并实施活动，在项目周期的后期进行系统集成活动；

1.6 RAD模型

RAD（Rapid Application Develop， 快速应用开发）模型是一个增量型的软件开发过程模型，强调极短的开发周期。该模型是 瀑布模型的一个“高速”变种，通过大量使用可复用 构件，采用基于构件的建造方法赢得了快速开发。

使用特点：

1）如果正确地理解了需求，而且约束了项目的范围，利用这种模型可以很快创建出功能完善的信息系统。其流程从业务建模开始，随后是数据建模、过程建模、应用生成、测试及反复。

2）RAD目的是快速发布系统方案，而技术上的优美相对发布的速度来说是次要的。

3）在需求得到很好理解、项目的范围约束明晰的前提下(通常不容易保证这样的条件)，采用RAD过程能够使项目组在很短的时间内(如60～90)天创建出功能完善的系统。

优点：

1）RAD模型通过大量使用可复用 构件加快了开发速度，对信息系统的开发特别有效。

2）RAD模型强调可复用程序构件的开发，支持多小组并行工作以缩短整体工期。

缺点：

1）对大型项目而言，RAD需要足够的人力资源。

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

3）并非所有系统都适合：不能合理模块化的系统、高性能需求并且要调整构件接口的系统均不适合。

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

二、 演进模型系列

2.1 原型模型

并非所有的需求都能够预先定义，大量的实践表明，在开发初期很难得到一个完整的、准确的需求规格说明。这主要是由于客户往往不能准确地表达对未来系统的全面要求，开发者对要解决的应用问题模糊不清，以至于形成的需求规格说明常常是不完整的、不准确的，有时甚至是有歧义的。此外，在整个开发过程中，用户可能会产生新的要求，导致需求的变更。而瀑布模型难以适应这种需求的不确定性和变化，于是出现了快速原型(Rapid Prototype）这种新的开发方法。

步骤：

1. 原型开发模型开始于沟通，开发人员和用户沟通，了解软件整体目标，明确已知需求，大致勾画出以后进一步定义的东西。
2. 然后迅速策划一个原型，进行建模；
3. 快速开发一个原型；
4. 对原型进行部署，由相关人员进行评价。
5. 根据评价进一步细化软件的需求。不断调整已满足需求。

使用特点：

1）原型方法比较适合于用户需求不清、需求经常变化的情况。当系统规模不是很大也不太复杂时，采用该方法比较好。

2）用户必须积极参与原型的建造，同时开发者和用户必须有共识：建造原型仅仅是为了定义需求，之后就必须被全部抛弃(至少是部分抛弃)，实际的软件必须在充分考虑到软件质量和可维护性之后才被开发。从这个意义上说，原型模型又往往被称为“抛弃原型模型”。

3）必须有快速开发工具可供使用。

优点：

1）克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险。
2）这种模型适合预先不能确切定义需求的软件系统的开发。

缺点： 

1）所选用的开发技术和工具不一定符合主流的发展；
2）快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。
3）使用这个模型的前提是要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新。

2.2 边建(做)边改

当一个软件产品在没有规格说明或主要设计的情况下被开发时，开发者往往不得不重新对产品编码多次直到他们得到正确稳定的产品。这种开发模型就是边做边改模型。

开发者们首先开发出一个产品的最初版本给客户验收，然后开发团队开发一个新的版本再次给客户验收。这个过程一直持续到客户感觉产品满意为止。

使用特点：

因为这种模型没有包括编码前的开发阶段，所以它不被认为是一个完整的生命周期模型。然而在某些场合这种简单的方式非常有用。对于需求非常简单和容易明白，软件期望的功能行为容易定义，实现的成功或失败容易检验的工程可以使用这种模型。

优点：

适用于一些较小的程序开发，可以快速实现功能

缺点：

1）缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；

2）忽略需求环节，给软件开发带来很大的风险；

3）没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。

2.3 增量模型(推荐)

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

使用特点：

融合了瀑布模型的基本成分和原型实现的迭代特征，可以有多个可用版本的发布，核心功能往往最先完成，在此基础上，每轮迭代会有新的增量发布，核心功能可以得到充分测试。强调每一个增量均发布一个可操作的产品。

增量模型适用于具有以下特征的软件开发项目：

1、软件产品可以分批次地进行交付。

2、待开发的软件系统能够被模块化。

3、软件开发人员对应用领域不熟悉，难以一次性地进行系统开发。

4、项目管理人员把握全局的水平较高。

优点：

增量模型作为瀑布模型的一个变体，具有瀑布模型的所有优点。此外，它还有以下优点：

1）将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展。

2）以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统。

3）开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时地对实现顺序进行调整。

缺点：

1）要求待开发的软件系统可以被模块化。如果待开发的软件系统很难被模块化，那么将会给增量开发带来很多麻烦。

2）如果没有对用户的变更要求进行规划，那么产生的初始增量可能会造成后来增量的不稳定；

3）如果需求不像早期思考的那样稳定和完整，那么一些增量就可能需要重新开发，重新发布;

4）管理发生的成本、进度和配置的复杂性可能会超出组织的能力。

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

2.4 螺旋模型(推荐)

螺旋模型是一种演化软件开发过程模型，它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。螺旋模型最大的特点在于引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。同时，在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。

使用特点：

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

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

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

4）螺旋模型更适合大型的昂贵的系统级的软件应用，特别适合于大型复杂的系统。

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

优点：

1）设计上的灵活性,可以在项目的各个阶段进行变更。

2）以小的分段来构建大型系统,使成本计算变得简单容易。

3）客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。

4）随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。

5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。

6）由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。

7）对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标；减少了过多测试（浪费资金）或测试不足（产品故障多）所带来的风险；更重要的是，在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别。

缺点：

1）很难让用户确信这种演化方法的结果是可以控制的。

2）建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。

2.5 并发模型

并行模型主要以开发过程中的主要技术活动和任务为框架，描述了开发过程中主要技术活动和任务的并行性。并行开发模型关注开发活动之间的并行性以及它们的相互关系，使项目管理者能够了解其项目当前的总体状态，便于他们有针对性地实施有效的项目管理。

使用特点：

1）并行模型强调开发周期短，并且需求充分理解且项目范围受限，且高度模块化。

2）常用于开发C/S系统

优点：

并行进行，开发周期短

缺点：

1）“并行”需要大量的人力资源，随着项目的复杂程度增加所需要的人力资源大于线性增加。
2）项目在实际开发中经常会有组件间的调整，并行开发无法解决。
3）一旦项目存在较高的技术风险（新技术），并行开发可能发生严重的后果。

2.6 XP模型(推荐)

极限编程是一个轻量级的、灵巧的软件开发方法，同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气（任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。）

使用特点：

1）不适用于不熟悉的领域（技术）或太复杂的软件开发。

2）XP适用于规模小、进度紧、需求变化大、质量要求严的项目。它希望以最高的效率和质量来解决用户目前的问题，以最大的灵活性和最小的代价来满足用户未来的需求，XP在平衡短期和长期之间做了巧妙的安排

3）一般适用于小型项目

优点：

1）开发周期短

2）软件质量有保证

3）适应用户需求变化，因此与用户关系和谐

4）重视客户的参与；重视团队合作和沟通；

5）让编程人员参与软件功能的管理；

缺点：

1）实际应用存在一些问题与争议。

2）与ISO9001、CMMI的精神存在冲突

3）以代码为中心，忽略了设计；

4）缺乏设计文档，局限于小规模项目；

5）对已完成工作的检查步骤缺乏清晰的结构；

2.7 RUP模型(推荐)

RUP（Rational Unified Process），统一软件开发过程，统一软件过程是一个面向对象且基于网络的程序开发方法论。

RUP最重要的它有三大特点：1）软件开发是一个迭代过程，2）软件开发是由Use Case驱动的，3）软件开发是以架构设计（Architectural Design）为中心的。

使用特点：

特别适用于大型软件团队开发大型项目。

优点：

1）提高了团队生产力，在迭代的开发过程、需求管理、基于组件的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面，针对所有关键的开发活动为每个开发成员提供了必要的准则、模板和工具指导，并确保全体成员共享相同的知识基础。

2）它建立了简洁和清晰的过程结构，为开发过程提供较大的通用性。

缺点：

1）RUP只是一个开发过程，并没有涵盖软件过程的全部内容，例如它缺少关于软件运行和支持等方面的内容；

2）此外，它没有支持多项目的开发结构，这在一定程度上降低了在开发组织内大范围实现重用的可能性。

三、 其他模型系列

3.1 构建组装CBD模型

基于构建开发模型（component-based development model），是指采用预先打包的软件构件开发应用系统。

使用特点：

1）项目开发经费较少

2）开发周期较短

优点：

1）软件复用，减少开发费用，缩短开发周期。

2）开销较小：CBD把成本效率提高到软件复用方法的最高境界。

3）方便装配：CBD的最大特征是一系列构件的装配过程。

4）复用性较高：全面考虑构件在多个应用系统中的复用潜力。

5）可维护性较强：在系统中可以方便地添加、删除和修改构件。

缺点：

需要需求妥协，不完全符合用户需求。

3.2 形式化方法模型

形式化方法模型（formal methods model），生成计算机软件形式化的数学规划说明。开发人员可以应用符号来说明、开发、验证基于计算机的系统。

使用特点：

1）质量要求较高

2）开发周期长

优点：

容易发现和改正歧义性、不完整、不一致问题。

缺点：

1）开发耗时，成本很高。
2）极少数程序员具有应用形式化方法的背景
3）对于技术水平不高的客户，很难用这种模型进行沟通。

4）一定程度上会延误项目开发周期、增加开发费用。

3.3 IDEAL模型

IDEAL模型代表了过程改进活动的⼀个⽣命周期，它作为⼀个基础性的策略，已经在SEI的许多服务中采⽤。IDEAL模型是⽤过程改进的五个阶段描述来命名的：

1. I——初始化(Initiating)，确定改进的⽬标并获得改进的基础结构；
2. D——诊断(Diagnosing)，确定现状与改进⽬标之间的差异；
3. E——建⽴(Establishing)，计划如何达成⽬标；
4. A——⾏动(Acting)，根据计划开展⼯作；
5. L——学习(Learning) ，从经验中学习，以提⾼未来组织过程的效能。

使用特点：

1）适用于具备一定的管理和技术能力的开发团队

2）开发时间充裕

优点：

1）结构化：IDEAL模型提供了一个明确的五阶段结构，为组织提供了一个系统化的方法来管理和实施过程改进。
2）经验总结：通过学习阶段，组织可以收集并分析改进过程中的经验教训，从而不断完善和提升软件开发过程。
3）持续改进：IDEAL模型强调了持续改进的重要性，通过不断学习和调整，组织可以不断提升其软件开发过程的效率和质量。

缺点：

1）实施复杂性：IDEAL模型需要组织投入大量的资源和精力来实施，包括建立过程基础设施、开展诊断评估、制定行动计划等。
2）时间成本高：IDEAL模型的实施需要经历五个阶段，每个阶段都需要一定的时间和精力投入，因此可能会导致实施周期较长。
3）依赖人员素质：IDEAL模型的成功实施需要组织具备一定的管理和技术能力，如果组织缺乏相关人员素质，则可能影响到模型的有效性。

四、参考文献

1. 线性顺序模型_百度百科 (baidu.com)
2. 瀑布模型_百度百科 (baidu.com)
3. 软件过程模型（软件开发模型）-CSDN博客
4. V模型_百度百科 (baidu.com)
5. RAD（Rapid Application Develop，快速应用开发）模型_快速开发模型-CSDN博客
6. 快速原型模型_百度百科 (baidu.com)
7. 边做边改模型_百度百科 (baidu.com)
8. 增量模型_百度百科 (baidu.com)
9. 螺旋模型_百度百科 (baidu.com)
10. 【软件工程】常见七种过程模型介绍_软件工程模型-CSDN博客
11. 极限编程（XP）：概念、特点和应用_不属于xp极限编程特点是-CSDN博客
12. RUP_百度百科 (baidu.com)
13. 基于构件开发方法的概念、目标和意义 - 过河的卒子 - 博客园 (cnblogs.com)
14. 软件工程——形式化方法概述_软件工程形式化技术优点和缺点?-CSDN博客
15. CMMI之IDEAL模型 - 百度文库 (baidu.com)