软件工程概述

软件生存期模型

软件工程第一部分第2章，主讲人：李欣

Created: 2024-03-05 Tue 16:42

0.1. 互动课堂

Click to host the seminar.

0.2. 签到

https://dash.memopixel.com/tool/attendance/

0.3. 本次课的目标

第一部分软件工程概述
- 第2章：软件生存期模型
  - 瀑布模型
  - 快速原型 模型
  - 增量模型
  - 螺旋模型
  - 喷泉模型
  - 统一过程
  - 基于构件 的开发模型
  - 敏捷过程

软件生存期模型 也称为软件过程模型，是从软件项目需求定义直至软件运行维护为止，跨越整个生命周期的系统开发、运行和维护所实施的全部过程、活动和任务的 结构框架 。

到目前位置，已经提出了多种软件生存期模型，典型的包括：
- 瀑布模型
- 原型模型
- 增量模型
- 螺旋模型
- 统一过程
- 敏捷过程
- ……

1. 瀑布模型

在20世纪80年代之前， 瀑布模型 一直是唯一被广泛采用的软件生存期模型。

传统软件工程方法学的软件过程基本上可以用 瀑布模型 来描述。

1.1. 传统的瀑布模型

%%{init: { 'theme': 'forest', 'fontFamily': 'Times New Roman, KaiTi' }}%%
graph LR
    A["需求分析<br>--------<br>验证"] --> B["规格说明<br>--------<br>验证"]
    B --> C["设计<br>--------<br>验证"]
    C --> D["编码<br>--------<br>测试"]
    D --> E["综合测试"]
    E --> F["维护"]

Figure 1: 传统的瀑布模型

传统瀑布模型 的特点

阶段间具有 顺序性 和 依赖性
1. 必须等前一阶段的工作完成后才能开始后一阶段工作；
2. 前一阶段的输出文档就是后一阶段的输入文档。
推迟实现 的观点
1. 系统分析和系统设计阶段的基本任务规定主要考虑目标系统的逻辑模型；
2. 清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现。
质量保证 的观点
1. 每个阶段都必须完成规定的文档；
2. 每个阶段结束前都要对所完成的文档进行评审。

1.2. 实际的瀑布模型

%%{init: { 'theme': 'forest', 'fontFamily': 'Times New Roman, KaiTi' }}%%
graph LR
    A["需求分析<br>--------<br>验证"] --> B["规格说明<br>--------<br>验证"]
    B --> A
    B --> C["设计<br>--------<br>验证"]
    C --> B
    C --> D["编码<br>--------<br>测试"]
    D --> C
    D --> E["综合测试"]
    E --> D
    E --> F["维护"]
    F .-> B
    F .-> C
    F .-> D
    F .-> G["变化的需求<br>--------<br>验证"]
    G .-> B

Figure 2: 实际的瀑布模型

实际瀑布模型 的特点

带反馈环，实线箭头表示开发过程，虚线箭头表示维护过程；
后面阶段发现前面阶段的错误时，需要沿反馈线返回前面阶段，修正后再继续后面阶段的任务。

1.3. V模型

%%{init: { 'theme': 'forest', 'fontFamily': 'Times New Roman, KaiTi' }}%%
graph LR
    A["需求建模"] ==> B["概要设计"] ==> C["详细设计"] ==> D["编码"] ==> X(["可执行软件"])
    X ==> E["单元测试"] ==> F["集成测试"] ==> G["系统测试"] ==> H["验收测试"]
    E --> D
    E --> C
    F --> C
    F --> B
    G --> B
    G --> A
    H --> A

Figure 3: V模型

V模型 的特点

经典生存期模型和 V模型没有本质区别；
V模型提供了一种将测试活动应用于早期软件工程工作中的方法。

1.4. 瀑布模型优缺点

瀑布模型优点

可强迫开发人员采用规范化的方法；
严格地规定了每个阶段必须提交的文档；
要求每个阶段交出的所有产品都必须是经过验证（评审）的。

瀑布模型缺点

若需求规格说明与用户需求之间有差异，会导致开发的软件产品不能真正满足用户需要；
瀑布模型只适用于项目开始时需求已确定的情况。

2. 快速原型模型

快速原型 是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是

最终产品功能的一个子集。

%%{init: { 'theme': 'forest', 'fontFamily': 'Times New Roman, KaiTi' }}%%
graph LR
    A["需求分析<br>--------<br>验证"] --> B["规格说明<br>--------<br>验证"]
    B --> C["设计<br>--------<br>验证"]
    C --> D["编码<br>--------<br>测试"]
    D --> E["综合测试"]
    E --> F["维护"]
    F .-> B
    F .-> C
    F .-> D
    F .-> G["变化的需求<br>--------<br>验证"]
    G .-> B

Figure 4: 快速原型模型

2.1. 快速原型模型的优点

有助于满足用户的真实需求；

原型系统已经通过与用户的交互而得到验证，产生的规格说明文档能够正确地描述用户需求；

软件产品的开发基本上是按线性顺序进行；

因规格说明文档正确描述了用户需求，后续开发过程不会进行较大返工；

开发人员通过建立原型系统已经学到很多东西，因此，在设计和编码阶段发生错误的可能性比较小；

快速原型的本质是快速，一旦需求确定，便可抛弃原型或在原型的基础上进行开发。

3. 增量模型

增量模型 也称为渐增模型，是Mills等人于1980年提出来的。使用增量模型开发软件时，把软件产品作为一系列的 增量构件 来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。

使用增量模型开发字处理软件的例子

第一个 增量构件提供最基本的文件管理、编辑和文档生成功能；
第二个 增量构件提供更完善的编辑和文档生成功能；
第三个 增量构件实现拼写和语法检查功能；
第四个 增量构件完成高级的页面排版功能。

%%{init: { 'theme': 'forest', 'fontFamily': 'Times New Roman, KaiTi' }}%%
graph LR
    A["需求分析<br>--------<br>验证"] --> B["规格说明<br>--------<br>验证"]
    B --> C["概要设计<br>--------<br>验证"]
    C --> D["针对每个构件<br>完成详细设计、编码和集成<br>经测试后交付给用户"]
    D --> D
    D --> E["维护"]
    E .-> D

Figure 5: 增量模型

增量模型 的优点

能够在较短的时间内向用户提交一些有用的工作产品；
逐步增加产品的功能可以使用户有较充裕的时间学习和适应新产品；
项目失败的风险较低，某些增量构件遇到问题时仍有可交付给用户的其他增量构件；
优先级最高的服务首先交付，然后将其他构件逐次集成进来，可保证最重要的系统服务接受最多的测试。

3.1. 增量构件开发

%%{init: { 'theme': 'forest', 'fontFamily': 'Times New Roman, KaiTi' }}%%
gantt
    title 软件系统
    dateFormat  YYYY-MM-DD
    section 增量1
    分析 : a1, 2022-01-01, 2d
    设计 : a2, after a1, 2d
    编码 : a3, after a2, 2d
    测试 : after a3, 2d
    section 增量2
    分析 : b1, 2022-01-02, 2d
    设计 : b2, after b1, 2d
    编码 : b3, after b2, 2d
    测试 : after b3, 2d
    section 增量3
    分析 : c1, 2022-01-03, 2d
    设计 : c2, after c1, 2d
    编码 : c3, after c2, 2d
    测试 : after c3, 2d
    section 增量4
    分析 : d1, 2022-01-04, 2d
    设计 : d2, after d1, 2d
    编码 : d3, after d2, 2d
    测试 : after d3, 2d

Figure 6: 增量构件开发

将软件产品分解成一系列的 增量构件 ，在增量开发迭代中 逐步加入 ；

构件需 规模适中 ，并且新构件集成到已有软件所形成的新产品必须是 可测试 的。

3.2. 采用增量模型的注意事项

在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏已经开发出来的产品；
软件体系结构必须是开放的，即向现有产品中加入新构件的过程必须简单、方便。

采用 增量模型 比采用 瀑布模型 和 快速原型模型 更需要精心的设计。

4. 螺旋模型

螺旋模型 最初是Boehm于1988年提出来的。该模型将瀑布模型与快速原型模型结合起来，并且加入两种模型均忽略了的 风险分析 。

4.1. 简化的螺旋模型

螺旋模型的 基本思想 是，使用原型及其他方法来尽量降低风险。

理解这种模型的一个简便方法，是把它看作在每个阶段之前都增加了 风险分析过程 的快速原型模型。

%%{init: { 'theme': 'forest', 'fontFamily': 'Times New Roman, KaiTi' }}%%
graph LR
    A["风险分析<br>--------<br>快速原型<br>--------<br>验证"] --> B["风险分析<br>--------<br>规格说明<br>--------<br>验证"]
    B --> C["风险分析<br>--------<br>设计<br>--------<br>验证"]
    C --> D["风险分析<br>--------<br>编码<br>--------<br>测试"]
    D --> E["风险分析<br>--------<br>综合测试"]
    E --> F["维护"] .-> G["风险分析<br>--------<br>变化的需求<br>--------<br>验证"]
    F .-> B
    F .-> C
    F .-> D
    G .-> B

Figure 7: 简化的螺旋模型

4.2. 完整的螺旋模型

Figure 8: 完整的螺旋模型

Determine objectives 确定目标
Identify and resolve risks 识别和解决风险
Development and Test 开发和测试
Plan the next iteration 计划下一次迭代
Review 审查
Cumulative cost 累计成本
Concept of requirements 需求概念
Concept of operation 运行理念
Requirements plan 需求计划
Operational prototype 可运行原型

4.3. 螺旋模型解读

在螺旋模型中，软件过程表示成一个螺线，而不是像以往的模型那样表示为一个具有回溯的活动序列。

在螺线上的每一个循环表示过程的一个阶段。

循环

最内层的循环 可以是处理系统可行性；
下一层循环 是研究系统需求；
再下一层循环 是研究系统设计；
……

阶段

每个阶段开始时的任务是 确定该阶段的目标 、为完成这些目标选择方案及设定这些方案的约束条件。
接下来的任务是， 从风险角度分析上一步的工作结果 ，努力排除各种潜在的风险，通常用建造原型的方法来排除风险。
如果成功地排除了所有风险，则启动下一步 开发步骤 ，在这个步骤的工作过程相当于纯粹的瀑布模型。
最后是 评价该阶段的工作成果 并计划下一个阶段的工作。

象限

螺线上的每一个循环可划分为 4个象限 ，分别表达了 4个方面的活动 。

目标设定 ：定义在该阶段的目标，弄清对过程和产品的限制条件，制订详细的管理计划，识别项目风险，可能还要计划与这些风险有关的对策。
风险估计与弱化 ：针对每一个风险进行详细分析，设想弱化风险的步骤。
开发与验证 ：评价风险之后选择系统开发模型。
计划：评价开发工作，确定是否继续进行螺线的下一个循环。如果确定要继续，则计划项目的下一个阶段的工作。

4.4. 螺旋模型优缺点

螺旋模型优点

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

螺旋模型缺点

螺旋模型是风险驱动的，因此要求软件开发人员必须具有丰富的风险评估经验和这方面的专门知识，否则将出现真正的风险—当项目实际上正在走向灾难时，开发人员可能还以为一切正常。

5. 喷泉模型

Figure 9: 喷泉模型\(^{[*]}\)

\([*]\) https://www.dicoding.com/blog/metode-sdlc/

喷泉模型 是典型的面向对象生命周期模型。喷泉一词体现了迭代和 无间隙 特性。图中代表不同阶段的圆圈相互重叠，这表示两个活动之间存在重叠。

名词	翻译
Analysis	（需求）分析
Requirements Specification	需求规格
Design	设计
Coding	编码
Testing and Integration	测试与集成
Operation	运行
Maintenance	维护
Evolution	进化（进一步开发）

6. 统一过程

Grady Booch Ivar Jacobson James Rumbaugh

UML

20世纪90年代早期，他们开始研究统一方法，其成果是 统一建模语言 （ Unified Modeling Language, UML ）。
UML 提供了支持面向对象软件工程实践必要的技术，但它没有提供指导项目团队应用该技术时的过程框架。
UML 是一种语言，并不是 方法论 。

RUP

他们接下来的努力是发布完全、统一的面向对象分析与设计的方法学，这种统一的方法学称为 Rational统一过程 （ Rational Unified Process, RUP ），也通常简称为 统一过程 。
RUP 是用 UML 进行面向对象软件工程的框架。

目前， 统一过程和UML广泛应用在各种各样的面向对象项目中。

6.1. 统一过程模型

Figure 10: Iterative Development

Figure 11: 统一过程模型

6个核心过程工作流 迭代过程中的阶段与传统瀑布模型中描述的阶段不同， 工作流 会在整个生命周期中一次又一次被访问。
9个核心工作流 在项目中轮流被使用，在每一次迭代中以不同的重点和强度重复。

6.2. 统一过程的核心过程工作流

统一过程中有6个 核心过程工作流（Core Process Workflows） 。

业务建模（Business Modeling）工作流 ：用业务用例为业务过程建立模型。
需求（Requirements）工作流 ：描述系统应该做什么，确保开发人员构建正确的系统。为此，需明确系统的功能需求和非功能需求（约束）。
分析与设计（Analysis & Design）工作流 ：分析和细化需求，并建立分析模型和设计模型。
实现（Implementation）工作流 ：用选择的实现语言实现目标系统。以分层的方式组织代码的结构，用构件的形式来实现类，对构件进行单元测试，将构件集成到可执行的系统中。
测试（Test）工作流 ：执行集成测试，验证对象之间的交互，是否所有的构件都集成了，是否正确实现了所有需求，查错并改正。测试类似于三维模型，分别从可靠性、功能性和系统性能这三个维度来进行。
部署（Deployment）工作流 ：制作软件的外部版本，软件打包、分发，为用户提供帮助和支持。

6.3. 统一过程的核心支持工作流

统一过程中有3个 核心支持工作流（Core Supporting Workflows） 。

配置与变更管理（Configuration & Change Management）工作流 ：描绘如何在多个成员组成的项目中控制大量的产物，如何管理并行开发、分布式开发，如何自动化创建工程，以及如何管理产品的修改原因、时间和人员审计记录。
项目管理（Project Management）工作流 ：平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功交付可使用户满意的产品。其目标包括：为 项目的管理 提供框架，为计划、 人员配备 、执行和 监控项目 提供实用的准则，为 管理风险 提供框架等。
环境（Environment）工作流 ：向软件开发组织提供软件开发环境，包括过程和工具。环境工作流集中于配置项目过程中所需要的活动，同样也支持开发项目规范的活动，提供了逐步的指导手册并介绍如何在组织中实现过程。

6.4. 统一过程的阶段

统一过程 有4个阶段，均以 里程碑 结束。 里程碑 意图是捕捉项目生命周期中的点，这些点上可能进行重大的管理决策和进展评估。

初始阶段 关注 项目计划和风险评估 ，确定是否值得开发目标系统，回答下面问题：
1. 目标系统是否是经济的？
2. 目标系统是否能按期交付？
3. 开发系统所涉及的风险是什么？
细化阶段 关心 定义系统的总体框架 ，有下面几个目标：
1. 细化初始需求；
2. 细化体系结构；
3. 监控风险并细化它们的优先级；
4. 细化业务用例以及制定项目管理计划。
构造（构建）阶段 是建立系统的第一个具有操作性的版本，以能够交付给客户进行测试的版本结束，有时称为测试版本。
移交阶段 以发布完整的系统而终止，其目标是确保系统真正满足客户的需求。

7. 基于构件的开发模型

基于构件的开发 是利用预先包装的构件来构造应用系统。构件可以是组织内部开发的，也可以是现有的商业成品构件（Commercial Off-The-Shelf, COTS）。

基于构件的软件工程（Component-Based Software Engineering, CBSE） 强调使用可复用的软件构件来设计和构造基于计算机的系统。

通常来讲，构件是计算机软件中的一个模块化的构造块。

7.1. 构件的定义

定义1

OMG（Object Management Group）统一建模语言规范给出的构件定义如下：

系统中模块化的、可部署的和可替换的部件，该部件封装了实现并暴露一系列接口。

定义2

国际上第一本软件构件专著《构件化软件—超越面向对象编程》（Szyperski）给出的构件定义如下：

一个构件是一个 组装单元 ，它具有约定式规范的接口，以及明确的 依赖环境 。构件可以被独立部署，由第三方组装。

7.2. 基于构件的开发模型图

Figure 12: 基于构件的开发模型

7.3. 基于构件的开发模型的思路

CBSE软件团队针对每一系统需求并不急于进行设计，而是询问如下问题。

现有的商业成品构件是否能够实现该需求？

内部开发的可复用构件是否能够实现该需求？

可用构件的接口与待构造系统的体系结构是否相容？

团队可以试图修改或去除那些不能用 COTS 或自有构件实现的系统需求。如果不能修改或去除这些需求，则必须应用软件工程方法构造满足这些需求的新构件。

7.4. 基于构件的开发模型的步骤

基于构件的开发模型中， 需求分析 和设计建模活动开始于识别可选构件，这些构件

有些设计成通用的软件模块，

有些设计成面向对象的类或 软件包 。

不考虑构件的开发技术， 基于构件的开发模型 由以下步骤组成。

对该问题领域的基于构件的可用产品进行 研究和评估 ；
考虑 构件集成 的问题；
设计 软件体系结构 （或称架构）以容纳这些构件；
将构件集成到体系结构中；
进行充分的测试以保证功能正常。

7.5. 基于构件的开发模型的好处

软件复用是提高软件生产率及软件质量的最有效的途径，而基于构件的软件开发比面向对象的软件开发实现了更大粒度的 软件复用 ，能够最大限度地 减少重复劳动 、 缩短开发周期 、 降低开发成本 ，从而使 软件生产率 得到提高；
由于已有的构件大都经过了很长时间的运行和测试，在质量方面比新开发的软件更有保证；
软件构件技术有助于软件设计的 标准化 和 设计风格 的改进与统一，进而提高系统间的 互操作性 ， 软件可靠性 和 可维护性 可以得到增强；
构件技术的研究和实践，能够积累和共享相关知识，使软件在 灵活性 和 标准化 等方面均得到改善，有助于实现软件开发的 工程化 、 工业化 和 产业化 。

8. 敏捷过程

2001年，以Kent Beck为首的敏捷联盟发表了 敏捷软件开发 宣言。

我们正在通过亲身实践以及帮助他人实践的方式来揭示更好的软件开发之路，通过这项工作，我们认为：

个体和交互 胜过过程和工具；

可工作软件 胜过宽泛的文档；

客户合作 胜过合同谈判；

响应变更 胜过遵循计划。

也就是说，虽然上述内容中右边的各项很有价值，但我们认为左边的各项具有更大的价值。

8.1. 什么是敏捷

Ivar Jacobson 给出以下论述：

敏捷团队是能够适当相应变更的灵活团队。变更就是软件开发本身，软件构建过程有变更、团队成员在变更、使用新技术会带来变更，各种变更都会对开发的软件产品以及项目本身造成影响。我们必须接受支持变更的思想，它应当根植于软件开发中的每一件事中，因为它是软件的心脏与灵魂。

敏捷团队意识到软件是团队中所有人共同开发完成的，这些人的个人技能和合作能力是项目成功的关键所在。

在 Jacobson 看来，普遍存在的变更是敏捷的基本动力，软件工程师必须加快步伐以适应 Jacobson 所描述的快速变更。

8.2. 敏捷方法适用的项目

从本质上讲，敏捷方法是为了克服传统软件工程中认识和实践的弱点而形成的。敏捷开发可以带来多方面的好处，但它并不适用于所有项目及产品。一般来说，敏捷方法更适合具有以下特征的软件开发项目。

提前预测哪些需求是稳定的、哪些需求会变更非常困难。同样的，预测项目进行中客户优先级的变更也很困难。
对很多软件，设计和构建是交错进行的。事实上f，两种活动应当顺序开展以保证通过构建来验证设计模型，而在通过构建验证之前很难估计应该设计到什么程度。
从制定计划的角度来看，分析、设计、构建和测试并不像我们所设想的那么容易预测。

8.3. 敏捷原则

敏捷联盟定义了以下 12 条敏捷原则：

尽早交付 我们最优先要做的是通过尽早、持续地交付有价值的软件来使客户满意。
欢迎变更 即使在开发的后期，也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势。
经常交付 经常交付可运行软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
持续工作 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
支持信任 围绕有积极性的个体构建项目，给他们提供所需的环境和支持，并且信任他们能够完成工作。
当面交谈 在团队内部，最富有效果和效率的信息传递方法是面对面交谈。
执行软件 可运行软件是进度的首要度量标准。
开发速度 敏捷过程提倡可持续的开发速度。责任人（Sponsor）、开发者和用户应该能够长期保持稳定的开发速度。
技能设计 不断地关注优秀的技能和好的设计会增强敏捷能力。
简单效率 简单—使不必做的工作最大化的艺术—是必要的。
组织团队 最好的架构、需求和设计出自于自组织团队。
反省调整 每隔一定时间，团队会反省如何才能更有效地工作，并相应调整自己的行为。

并不是每一个敏捷模型都同等使用这 12 项原则，一些模型可以选择忽略或淡化一个或多个原则的重要性。

8.4. 极限编程

极限编程（eXtreme Programming, XP） 是使用最广泛的敏捷过程，其相关思想和方法最早出现于20世纪80年代后期，但直到2000年Kent Beck撰写的《Extreme Programming Explained: Embrace Change》一书出版，它才引起软件业的极大关注。

XP使用 面向对象方法 作为推荐的开发范型，它包含了策划、设计、编码和测试 4个框架活动的规则和实践。

策划

策划活动 属于需求获取活动，通过倾听用户对软件需求的一系列描述（主要为功能描述，也成为用户故事），使XP团队成员理解软件的商业背景以及要求的输出、主要特征及主要功能。
客户和 XP团队 共同决定如何把故事分组，并置于XP团队将要开发的下一个发行版本中。一旦认可对下一个发行版本的基本承诺（包括故事、交付日期和其他项目事项）， XP团队将按以下三种方式之一对待开发的故事进行排序：
1. 所有选定故事将在几周之内 尽快实现 ；
2. 具有最高价值的故事将移到进度表的前面并 首先实现 ；
3. 高风险的故事将 首先实现 。
项目的第一个发行版本交付之后， XP团队计算项目的速度，即第一个发行版本中实现的用户故事个数，帮助建立后续发行版本的发布日期和进度安排，确定是否对整个开发项目中的所有故事有过分承诺。一旦发生过分承诺，则调整软件发行版本的内容或者改变最终交付日期。

设计

XP设计 严格遵循保持简洁（Keep It Simple, KIS）原则，使用简单而不是复杂的表述。另外，设计为故事提供不多也不少的实现原则，不鼓励额外功能性（开发者假定以后会用到）的设计。
XP的中心思想使设计可以在编码开始前后同时进行，重构意味着设计随着系统的构建而连续进行。实际上，构建活动本身将给XP团队提供关于如何改进设计的指导。

编码

XP推荐在故事开发和初步设计完成之后不应直接开始编码，而是开发一系列用于检测本次（软件增量）发布的包括所有故事的单元测试。一旦建立了单元测试，开发者就可以把精力更集中于必须实现的内容，以通过单元测试。不需要加任何额外的东西（保持简洁）。一旦编码完成，就可以立即完成单元测试，从而向开发者提供即时的反馈。
XP编码活动中的关键概念之一是结对编程。 XP推荐两个人面对同一台计算机共同为一个故事开发代码。这一方案提供实时解决问题和实时质量保证机制，同时也使开发者能集中精力解决当前的问题。实施中不同成员担任的角色略有不同。

测试

在编码开始之前建立单元测试是XP方法的关键因素。所建立的单元测试应当使用一个可以自动实施的框架，因此易于执行并可重复，这种方式支持代码修改之后及时的回归测试策略。
一旦将个人的单元测试组织到一个通用测试集，就可以每天进行系统的集成和确认测试，这可以为XP团队提供连续的进展指示，也可在一旦发生问题的时候及早提出预警。

8.5. 其他敏捷过程模型

敏捷过程模型中除了适用最广泛的XP ，还有许多其他 敏捷过程模型 ，它们也在行业中使用。较普遍的有以下几种：

自适应软件开发（Adaptive Software Development, ASD） 是由Jim Highsmith提出的，它可作为构建复杂软件和系统的一项技术，其基本概念着眼于 人员协作 和 团队自我组织 。生命周期包含思考、协作和学习三个阶段。
Scrum 得名于橄榄球比赛，其原则于敏捷宣言一致，同时强调使用一组软件过程模式，这些过程模式被证实在时间紧张的、需求变化的和业务关键的项目中是有效的。包含待定项（backlog）、冲刺（sprint）、 Scrum例会和演示。
敏捷建模（Agile Modeling, AM） 原则中独具特色的内容是有目的的模型、使用多个模型、轻装上阵、理解模型及工具和适应本地需要。
敏捷统一过程（Agile Unified Process, AUP） 采用在全局连续、在局部迭代的原理来构建基于计算机的系统。每个AUP迭代执行的活动包括建模、实现、测试、部署、配置及项目管理、环境管理。

9. 课后作业

习题2.1 瀑布模型、快速原型模型、增量模型及螺旋模型都是传统的软件过程模型，请给出各个模型的特点。每种模型的优点和缺点是什么？适用于哪些场合？
习题2.3 可以合用几种模型吗？如果可以，举例说明。
习题2.4 解释喷泉模型的特点及其适用的场合。
习题2.8 统一过程的4个阶段是什么？
习题2.11 简述敏捷软件开发的原则。