第5章：软件工程

软件过程

1. 能力成熟度模型（CMM）

CMM 将软件过程改进分为以下5个成熟度级别：

1）初始级（最低成熟度）

软件过程的特点是杂乱无章，有时甚至很混乱，几乎没有明确定义的步骤，项目的成功完全依赖个人的努力和英雄式核心人物的作用。

2）可重复级

建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性，有必要的过程准则来重复以前在同类项目中的成功。

3）已定义级

管理和工程两方面的软件过程已经文档化、标准化，并综合成整个软件开发组织的标准软件过程。

4）已管理级

制定了软件过程和产品质量的详细度量标准。软件过程的产品质量都被开发组织的成员所理解和控制。

5）优化级（最高成熟度）

加强了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进。

2. 能力成熟度模型集成（CMMI）

CMMI 提供了两种表示方法：

1）阶段式模型

阶段式模型的结构类似于 CMM，它关注组织的成熟度。

有五个成熟度等级：

- 初始的：过程不可预测且缺乏控制。

- 已管理的：过程为项目服务。

- 已定义的：过程为组织服务。

- 定量管理的：过程已度量和控制。

- 优化的：集中于过程改进。

2）连续式模型

连续式模型关注每个过程域的能力，一个组织对不同的过程域可以达到不同的过程域能力。

CMMI 中包括6个过程域能力等级：

-CL₀（未完成的）：过程域未执行或未得到 CL₁ 中定义的所有目标。

-CL₁（已执行的）：其共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品，以实现支持过程域的特定目标。

-CL₂（己管理的）：其共性目标集中于己管理的过程的制度化。

-CL₃（己定义级的)：其共性目标集中于己定义的过程的制度化。关注过程的组织标准化和部署。

-CL₄（定量管理的）：其共性目标集中于可定量管理的过程的制度化。

-CL₅（优化的)：使用量化（统计学）手段改变和优化过程域，以满足客户要求的改变和持续改进计划中的过程域的功效。

软件过程模型（软件开发模型）

常见的软件开发过程模型包括瀑布模型、增量模型、演化模型（原型模型、螺旋模型）和喷泉模型。

 瀑布模型（Waterfall Model）

瀑布模型是一种线性的软件开发过程模型，开发流程严格按照顺序依次进行，每个阶段都必须完成后才能进入下一个阶段。瀑布模型包括需求分析、设计、编码、测试、运行与维护五个阶段。（阶段评审和文档控制）

- 优点：

  - 容易理解、管理成本低

  - 每个阶段都有对应的成果产物

  - 各个阶段有明显的界限划分和顺序需求

  - 强调开发的阶段性早期计划及需求调查和产品测试

- 缺点：

  - 需要客户能够完整、正确和清晰地表达自己的需要

  - 在开始的两个或3个阶段中，很难评估真正的进度状态

  - 当接近项目结束时，出现了大量的集成和测试工作

  - 直到项目结束之前，都不能演示系统的能力

  - 一旦发生错误，整个项目要推到重新开始。

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

瀑布模式适合用于：

- 开发需求明确的，需求大致固定且不会随意变更的系统（已有原系统）

- 开发人员对软件的应用领域很熟悉

- 开发工作对用户参与的要求很低

V模型是瀑布模型的一个变体。

 增量模型（Incremental Model）

增量模型采用了逐步完善的思路，将软件的开发过程划分为一个个的增量，每个增量都能够独立实现某一或多项功能或特性。在逐步实现的过程中，可以不断根据需求变化来进行迭代，从而保证最终的软件达到客户需求和期望。（版本迭代）

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

- 第一个可交付版本所需要的成本和时间很少

- 开发由增量表示的小系统所承担的风险不大

- 由于很快发布了第一个版本，因此可以减少用户需求的变更

- 优先级高的功能先交付，使得重要的功能经历更多的测试

- 运行增量投资，即在项目开始时，可以仅对一个或两个增量投资

缺点：

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

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

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

增量模型适合用于：

- 需求尚不明确

- 需要快速构造可运行的产品的项目（对完成期限严格要求的产品）适宜商业开发

- 进行已有产品升级或新版本开发

- 对所开发的领域比较熟悉而且已有原型系统。

 演化模型(Evolutionary Model)

演化模型是迭代的过程模型，使得软件开发人员能够逐步开发出更完整的软件版本。演化模型特别适用于对软件需求缺乏准确认识的情况。典型的演化模型有原型模型和螺旋模型等。

 原型模型(Prototype Model)

并非所有的需求都能够预先定义。大量的实践表明，在开发初期很难得到一个完整的、准确的需求规格说明。

原型模型：

- 适合于用户需求不清、需求经常变化的情况

- 不适合大规模系统的开发

原型的目的是能快速、低成本地构建原型系统。

能够采用原型方法是因为开发工具的快速发展，使得能够迅速地开发出一个让用户看得见、摸得着的系统框架。这样，对于计算机不是很熟悉的用户就可以根据这个框架提出自己的需求。

开发原型系统首先确定用户需求，开发初始原型，然后征求用户对初始原型的改进意见，并根据意见修改原型:

螺旋模型（Spiral Model）

对于复杂的大型软件，开发一个原型往往达不到要求。

螺旋模型将瀑布模型和演化模型结合起来，加入了两种模型均忽略的风险分析（以风险为驱动），弥补了这两种模型的不足。

螺旋模型将开发过程分为几个螺旋周期(一个周期4个步骤)，每个螺旋周期大致和瀑布模型相符合：

螺旋模型适用于：

- 庞大、复杂并且具有高风险的系统；

- 新近开发，需求不明的情况。

优点：

- 支持用户需求的动态变化

- 螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，从而做出应有的反应。

- 螺旋模型支持用户需求的动态变化，有助于提高软件的适应能力，降低了软件开发的风险。

缺点：

- 需要开发人员具有相当丰富的风险评估经验和专门知识。

- 过多的迭代次数会增加开发成本，延迟提交时间。

 喷泉模型（Water Fountain Model）

喷泉模型：喷泉模型克服了瀑布模型不支持软件重用和多项开发活动集成的局限性

- 以用户需求为动力

- 以对象作为驱动

- 适合于面向对象

泉模型使开发过程具有以下性质或特点：

- 迭代性：意味着模型中的开发活动常常需要重复多次，在迭代过程中不断地完善软件系统。

- 无间隙性：指在开发活动（如分析、设计、编码）之间不存在明显的边界。喷泉不像瀑布模型那样，在需求分析活动结束后才开始设计活动，在设计活动结束后才开始编码活动，而是允许各开发活动交叉、迭代地进行。

- 支持软件重用。

优点：喷泉模型的各个阶段没有明显的界线，开发人员可以同步进行。可以提高软件项目的开发效率，节省开发时间。

缺点：

- 由于喷泉模型在各个开发阶段是重叠的，在开发过程中需要大量的开发人员，不利于项目的管理。

- 喷泉模型要求严格管理文档，使得审核的难度加大。

 统一过程（UP）模型 

统一过程（UP）模型是一种以用例和风险为驱动，以架构为中心，迭代并且增量的开发过程。              

阶段	里程碑（结束标志）	关注	产生
初始阶段	生命周期目标	项目的初创活动	构想文档、业务用例、项目计划、风险评估
精化阶段	生命周期架构	需求分析和架构演进	补充需求分析、软件架构描述、架构原型制品