[架构之路-153]-《软考-系统分析师》- 8-软件工程-3-软件开发模型（时间轴、阶段模型）

目录

第8章 软件工程

8.3 软件开发模型（时间轴模型）

8.3.1软件开发模型

1. 瀑布模型

2. 演化模型

3. 螺旋模型

4. 喷泉模型

5 . 变换模型

6 . 智能模型

7. V 模型

8.3.2 快速应用开发

8.3.3 统一过程

8.3.4 敏捷方法

第8章 软件工程

备注说明：

开发模型，是从时间的角度，为业务软件的开发构建了一个软件开发活动框架。

在该框架下，开展各种软件业务领域活动、计算机领域的活动、软件项目管理活动！！！

软件开发模型、以及软件工程大部分的知识，主要用于项目管理，对业务领域，如5G， ERP等没有太多的帮助，对计算机领域，如软件编程，架构设计等，都没有太多的帮助。

软件工程是指导软件开发人员如何从时间和阶段性的维度，来开展软件各种软件开发活动（包括业务领域和计算机领域）。

软件工程本身并不关注目标软件系统（业务知识+计算机知识）本身，它关注的是，如何按照工程化的方法，构建目标系统。

8.3 软件开发模型（时间轴模型）

软件开发模型给出了软件开发活动各阶段之间的关系，它是软件幵发过程的概括，是软件工程的重要内容。

软件开发模型为软件工程管理提供了里程碑和进度表，为软件幵发过程提供了原则和方法。

8.3.1软件开发模型

软件开发模型大体上可分为三种类型。

第一种是以软件需求完全确定为前提的瀑布模型；

第二种是在软件幵发初始阶段只能提供基本需求时采用的迭代式或渐进式幵发模型，例如，喷泉模型、螺旋模型、统一幵发过程和敏捷方法等；

第三种是以形式化幵发方法为基础的变换模型。

1. 瀑布模型

付一个完善的系统，并没有考虑软件的演化特征。其优点是强调开发的阶段性、早期计划及需求调查和产品测试，以这样严格的方式构造软件，开发人员很清楚每一步应该做什么，有利于项目管理。 |

然而，在瀑布模型中，依赖于早期进行的需求调査，不能适应需求的变化；

由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程；

风险往往迟至后期的开发阶段才显露出来，从而失去了及早纠正的机会。

在瀑布模型中，需求或设计中的错误往往只有到了项目后期才能够被发现，对于项目风险的控制能力较弱，从而导致项目常常延期完成，开发费用超出预算。

2. 演化模型

演化模型主要针对事先不能完整定义需求的软件开发，是在快速开发一个原型的基础上，根据用户在调用原型的过程中提出的反馈意见和建议，对原型进行改进，获得原型的新版本，重复这一过程，直到演化成最终的软件产品。演化模型的主要优点是，任何功能一经开发就能进入测试，以便验证是否符合产品需求，可以帮助引导出高质量的产品要求。其主要缺点是，如果不加控制地让用户接触开发中尚未稳定的功能，可能对开发人员及用户都会产生负面的影响。

3. 螺旋模型

螺旋模型是瀑布模型与演化模型相结合，并加入两者所忽略的风险分析所建立的一种软件开发模型。螺旋模型是一种演化软件过程模型，它将原型实现的迭代特征与线性顺序模型中控制的和系统化的方面结合起来，使软件的增量版本的快速开发成为可能。在螺旋模型中，软件开发是一系列的增量发布。

螺旋模型沿着螺线进行若干次迭代，每次迭代都包括制订计划、风险分析、实施工程和客户评估4 个方面的工作。螺旋模型强调风险分析，使得幵发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应。因此，特别适用于庞大、复杂并具有高风险的系统。

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

在使用螺旋模型进行软件幵发时，需要开发人员具有相当丰富的风险评估经验和专门知识。另外，过多的迭代次数会增加幵发成本，延迟提交时间。

4. 喷泉模型

喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。该模型认为软件开发过程自下而上的各阶段是相互重叠和多次反复的,就像水喷上去又可以落下来，类似一个喷泉。各个开发阶段没有特定的次序要求，并且可以交互进行，可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏。在喷泉模型中，各活动之间无明显边界，例如，分析和设计之间没有明显的边界。

这种特性称为无间隙性。由于对象概念的引入，只用类和关系来表达分析、设计和实现
等活动，从而可以较容易地实现活动的迭代和无间隙，提高软件项目幵发效率，节省幵
发时)旬。

5 . 变换模型

变换模型是基于形式化规格说明语言和程序变换的软件幵发模型，它对形式化的软
件规格说明进行一系列自动或半自动的程序变换，最后映射为计算机能够接受的软件系
统。为了确认形式化规格说明与软件需求的一致性，往往以形式化规格说明为基础开发
一个软件原型，用户可以从人机界面、系统主要功能和性能等方面对原型进行评审。必
要时，可以修改软件需求、形式化规格说明和原型，直至原型被确认为止。这时，开发
人员即可对形式化的规格说明进行一系列的程序变换，直至生成计算机可以接受的 H 标
代码。
程序变换是软件幵发的另一种方法，其基本思想是把程序设计的过程分为生成阶段
和改进阶段。首先，通过对问题的分析制订形式规范并生成一个程序，通常是一种函数
型的递归方程。然后，通过一系列保持正确性的源程序到源程序的变换，把函数型风格
转换成过程型风格，并进行数据结构和算法的求精，最终得到一个有效的面向过程的程
序。这种变换过程是一种严格的形式推导过程，所以只需对变换前的程序的规范加以验
证，变换后的程序的正确性将由变换法则的正确性来保证。
变换模型的优点是解决了代码结构经多次修改而变坏的问题，减少了许多中间步骤
(例如，设计、编码和测试等)。但是，变换模型仍有较大局限，以形式化开发方法为基
础的变换模型需要严格的数学理论和一整套开发环境的支持。

6 . 智能模型

智能模型也称为基于知识的软件开发模型，它综合了上述若干模型，并把专家系统结合在一起。该模型应用基于规则的系统，采用规约和推理机制，帮助开发人员完成幵发工作，并使维护在系统规格说明一级进行。为此，需要建立知识库，将模型本身、软件工程知识与特定领域的知识分别存入知识库。

7. V 模型

V 模型是在快速应用开发模型基础上演变而来，由于将整个幵发过程构造成一个 V字形而得名。 V 模型应用在软件测试方面，和瀑布模型有着一些共同的特征。 V 模型中的过程从左到右，描述了基本的开发过程和测试行为，其价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程各阶段的对应关系，如图8-3所示。在 V 模型中，单元测试是基于代码的测试，最初由开发人员执行，以验证程序代码的各个部分是否己达到预期的功能要求；集成测试验证了两个以上单元之间的集成是否正确，并有针对性地对详细设计中所定义的各单元之间的接口进行检査；在所有单元测试和集成测试完成后，系统测试开始以客户环境模拟系统的运行，以验证系统是否达到。

8.3.2 快速应用开发

R A D 只能用于管理信息系统的开发，不适合技术风险很高的情况。例如，当一个新系统要采用很多新技术，或当新系统要与现有系统有较髙的互操作性时，就不适合使用 R A D 。

8.3.3 统一过程

 

 

8.3.4 敏捷方法