这一章我们要详细分析软件工程中的各种步骤的组织方式，以便我们协调各种活动。面对的主要问题有如何理解过程模型，如何应对软件开发过程中的种种状况，为此我们首先要解释过程模型的意义，然后为大家介绍各种模型的思想，为了响应变化和规避风险，会涉及到原型化和迭代开发的思想。关键在于思想的理解，模型是固化的，思想运用是灵活的。本章重点在过程与生命周期和过程模型。

章节框架：

过程与生命周期

过程的定义

一组有序的任务，它涉及活动、约束和资源使用的一系列步骤，用于产生某种想要的输出。

过程不仅仅是步骤，过程是步骤的集合，它将步骤组织起来使人们能够生产满足一系列目标和标准的产品。

软件生命周期

软件开发过程描述了软件产品从概念到实现、交付、使用和维护的整个过程，因此，有时把软件开发过程称为软件生命周期。

过程的重要意义

1. 它强制活动具有一致性和一定的结构。

2. 过程结构允许我们分析、理解、控制和改进组成过程的活动，并以此来指导我们的活动。

3. 它使我们获取经验并把经验传授给他人。

过程模型

为何需要为过程建立模型:

1. 达成共识：开发团队在记录开发过程的描述时，自然的对软件所涉及到的活动,资源,约束等达成共识，这共识就是”模型”。

2. 发现缺陷：发现过程层面的缺陷(过程实施时的不一致性、多余部分、缺省部分、不完善部分)，从而让过程更有效。

3. 评价与优化：模型应该反映开发的诸多目标，并评价侯选活动的有效性和正确性,以构建高质量软件。

瀑布模型

线性的安排每一个阶段，将开发阶段描述为从一个阶段瀑布般地转换到另一个阶段。一个开发阶段必须在另一个开发阶段开始之前完成。

瀑布模型的优点

1. 它的简单性使得开发人员很容易向不熟悉软件开发的客户作出解释。

2. 每一个过程活动都有与其相关联的里程碑和可交付产品，以便于项目经理评估项目进度。

3. 瀑布模型是最基础的模型，很多其他更复杂的模型实际上是在瀑布模型的基础上的润色，如加入反馈循环以及额外的活动。

瀑布模型的缺点

1. 除了一些理解非常充分的问题之外，实际上软件是通过大量的迭代进行开发的。软件是一个创造的过程,
   不是一个制造的过程。软件变动时,
   该模型无法处理实际过程中的重复开发问题。

2. 文档转换有困难。它说明了每一个活动的产品（例如，需求、设计或代码），但没有揭示一个活动如何把一种制品转化为另外一种制品（例如，从需求文档转化为设计文档）。

瀑布模型的优化——原型化的瀑布模型

我们注意到瀑布模型将过程抽象为线性发展的，这种抽象给它带来了简单、明确和直观的优点，但同时也招致了许多问题。可是实际的开发中每个步骤并不是理想中的线性发展的的状态，比如在设计阶段了解到客户更新了需求，或者在设计阶段的疏漏直到测试时才被发现，以上的情况都需要返回之前的步骤进行修正才能解决。我们需要对瀑布模型进行优化，引入原型化以有助于控制活动之间的往返。

原型的概念

一种部分开发的产品，用来让用户和开发者共同研究，提出意见，为最终产品定型。

原型可以理解为小样，在某一阶段产品定型前先做一些小样，通过对各种样品的评价和分析，并最终为产品定型。

原型化的瀑布模型如下图所示，在实现代码前的需求和设计阶段引进原型化的概念，在需求分析阶段，通过设计和分析原型以确保需求是一致、可行和符合实际的，避免在测试阶段付出巨大的代价进行修正；在设计阶段，原型化有助于开发人员评价可选的设计策略以及决定哪一种策略是最适合的。为了确保产品符合需要，在测试阶段要进行确认/核准（validate）和验证（verify）。

区分确认和验证

确认：确保系统实现了所有需求。

验证：确保每一项功能都是正确的。

确认保证开发人员构造的是正确的产品，而验证检查实现的质量。

V 模型

V 模型是瀑布模型的变种，它说明测试活动是如何与分析和设计相联系的。

如下图所示，编码位于 V型的顶点，分析和设计在左边，测试和维护在右边。测试的每个步骤都与分析和设计相对应，如果在验证和确认期间发现了问题，可以重新执行响应的步骤加以修正。验收测试对应需求分析，系统测试对应系统设计，单元测试和集成测试对应程序设计。

V 模型与瀑布模型的区别：

1. V 模型使得隐藏在瀑布模型中的迭代和重做活动更加明确。

2. 瀑布模型关注文档和制品，V 模型关注活动和正确性。

原型化模型——“在工作中学会工作”

之前在瀑布模型的优化中介绍了原型化的思想，原型化并不依附于瀑布模型，原型化模型本身是有效的过程模型的基础。因为它允许用户以独立的工程模型的方式,
每一阶段都基于原型的建立, 以快速构造系统, 逐步完成各阶段任务。

如上图所示，原型化模型并不依赖于明确的需求或设计，在情况不明朗的情况下使用原型化模型，先根据简单的需求和设计构造系统的简单样品以理解或澄清问题，以确保开发人员、用户和客户对产品达成共识。也就是说，要根据对每一阶段样品的反响明确需求和设计的具体内容。原型化设计有助于开发人员和客户达成共识，减少了开发中的风险和不确定性。但是为达成共识可能会需要反复进行原型设计。

阶段化开发模型

系统被设计成部分提交, 每次用户只能得到部分功能,而其他部分处于开发过程中。

循环周期：从软件开发时整理需求文档到系统交付经过的时间。

理解为何要阶段化开发，我们需要了解现在的商业环境不允许产品长时间拖延，所以我们要缩短循环周期，使用阶段化开发模型使系统能一部分一部分的交付，从而在系统其余部分正在开发的同时，用户已经获得了一部分功能。

产品系统和开发系统

因为一边开发一边交付，所以有两个系统在并行运行。

运行系统/产品系统：当前正在被客户和用户使用的系统。

开发系统：准备代替现行产品系统的下一个版本。

两者关系如下图所示，开发人员总是在开发 n+1，而与此同时 n 正在运行。

增量开发和迭代开发

因为有不断发布的开发系统和已经运行的产品系统，我们需要有一种组织两者的方式。增量开发和迭代开发是两种最常用的方式。

增量开发：系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能的子系统集。

迭代开发：系统开始就提供了整体功能框架，后续版本陆续增强各个子系统，最后版本使各个子系统的功能达到最强。

将增量开发和迭代开发相结合

一个新发布的版本可能包含新功能，并对已有功能做了改进。

两种开发方式结合的原因：

1. 观察用户反馈。
2. 为新功能开拓市场。
3. 及时修复问题。
4. 针对不同版本设置不同专业领域技术的优化。

进化式迭代开发

统一过程（UP/RUP）：用例驱动的、以基本架构为中心的、迭代式和增量性的软件开发过程框架。它使用对象管理组织（OMG）的 UML并与对象管理组织（OMG）的软件过程工程原模型（SPEM）等相兼容。

统一过程的特点

• 统一过程”将重复一系列生命期，这些生命期构成了一个系统的寿命。每个生命期都以向客户推出一个产品版本而结束。
• 每个周期包括四个阶段：开始阶段、确立阶段、构建阶段和移交阶段。每个阶段可以进一步划分为多次迭代。

三个支持工序和六个核心工序

支持工序：

1. 配置变更管理工序，用来管理系统和需求变更的配置。
2. 项目管理工序，用来管理项目。
3. 环境配置工序，用来配置项目的环境，包括所涉及到的过程和工具。

核心工序：

1. 业务模型工序，通过业务模型获取相关知识以理解需要系统自动完成的业务。
2. 需求工序，通过用例模型获取相关知识以理解自动完成业务的系统需求。
3. 分析设计工序，通过分析/设计模型以分析需求，设计系统结构。
4. 实现工序，基于实现模型实现系统。
5. 测试工序，通过测试模型进行针对需求的系统测试。
6. 部署工序，通过部署模型部署系统。

下图展示了统一过程的四个阶段和六个核心工序之间的关系，上面一行表示四个阶段，左边一列表示六个核心工序，二者都包含在软件项目的生命期中。每个阶段都包含六个工序，但是重点不同。开始阶段最关注业务模型，几乎不涉及测试和部署；确立阶段最关心需求和分析；构建阶段最关心实现；移交阶段最关心测试和部署，几乎不涉及业务模型和需求。图中箭头表示六个工序执行顺序，菱形覆盖的面积表示关注程度。

什么是进化式迭代开发

1. 进化式迭代开发是统一开发过程的关键实践。
2. 开发被组织成一系列固定的短期小项目。
3. 每次迭代都产生经过测试、集成并可执行的局部系统。
4. 每次迭代都具有各自的需求分析、设计、实现和测试。
5. 随着时间和一次次迭代，系统增量式完善。结合下图理解进化式迭代开发。

螺旋模型

此法将开发活动与风险管理结合起来,以降低和控制风险。有些类似于迭代开发模型，结合了迭代的思想，同时也结合了原型化的思想。该模型的适用范围于较大型软件工程项目。

如下图所示，螺旋模型每次迭代有四个任务，依次是计划、目标/可选方案、风险评估、开发与测试。螺旋模型共有四次迭代，依次是操作概念、软件需求、软件设计、开发与测试。]每一次迭代都根据需求和约束进行风险分析，以权衡不同选择，并且在确定选择之前，通过原型化验证可行性和期望度。

敏捷方法

之前介绍的几种模型逐渐引入了原型化和迭代开发的思想，使得过程模型变得庞大，而敏捷方法打破了这种局面。

敏捷方法强调灵活性在快速有效的软件生产中所发挥的作用，是重量级方法的叛逆者。

敏捷方法的四条原则

1. 个体和交互的价值胜过过程和工具。
2. 可以工作的软件胜过面面俱到的文档。
3. 客户合作胜过合同谈判。
4. 响应变化胜过遵循计划。

这四条原则反映了敏捷方法的软件过程倾向性。它强调人与人之间的交互是复杂的，并且其效果从来都是难以预期的，但却是工作中最重要的方面。

敏捷开发的总体目标：尽可能早的，持续的对有价值的软件的交付活动，以客户满意。

敏捷开发过程的几种方法

1. 极限编程(XP)：激发人员创造性，使管理负担最小的一组技术，是敏捷方法中最主要的流派。（稍后有详细介绍）
2. Crystal（水晶法）：每一个不同的项目都需要一套不同的策略、约定和方法论。
3. SCRUM（并列争球法）：使用迭代的方法，其中把每 30天一次的迭代称为一个”冲刺”，并按需求的优先级别来实现产品。
4. Adaptive Software Development(ASD) (自适应软件开发)
5. Feature Driven Development(FDD) (特征驱动软件开发)

极限编程

四个变量

成本、时间、质量和范围，通过研究变量之间的相互作用，将项目开发分析的更加透彻，成功讲述一个项目成功的原则。

不同的任务对这四个变量有不同的要求，分析哪一个变量是项目进展的制约，集中精力解决关键问题。

四个准则

1. 沟通: 客户与开发者之间持续的交流意见。
2. 简单性: 鼓励开发者选择最简单的设计或实现来应对客户的需求。
3. 反馈: 指在软件开发过程中的各个活动中,包含各种反馈循环工作。
4. 勇气: 指尽早的和经常性的交付软件功能的承诺。

十二条原则

计划游戏、小版本、隐喻、简单设计、测试、重构、结队编程、代码集体所有、持续集成、每周工作40 小时、现场客户、编码标准

• 小版本：系统设计要支持尽可能早的交付。（测试要简单有效。）

• 简单设计：只处理当前需求，使设计保持简单。（因为假设需求是变化的）

• 编码标准：编码支持其他实践，例如测试和重构等。

  其余每条的介绍详见课本。

例题

关于小版本(小型发布)的说明：敏捷开发方法中，对计划的发布版本应该（ B）。

A：按产品特性交付：需要交付的特性都必须交付，必要时要推迟发布时间

B：按日期交付：按照预定发布时间进行发布，必要时候裁剪部分功能特性。

C：临时决定：我们会平衡一下，临时根据市场要求和开发进展来确定，可能会同时调整交付时间和特性。

D：在迭代模式下，没有必要计划版本。每个迭代都应该完成可发布的版本，按照市场需要发布迭代版本即可。

解析：敏捷方法强调灵活性，”尽可能早的，持续的对有价值的软件的交付活动”是其总体目标。

过程建模工具和技术

建模工具与技术是在过程模型之内的具体运用。

两种主要种类的模型

静态建模——Lai 表示法

描述一个过程如何由输入转换为输出。

综合的过程符号描述系统, 允许人们在任何详细的层次上对任何过程建模,该模型范式中可由人员完成角色,由资源完成活动,最后导致软件工件/制品的产生。过程模型可以用角色、活动、加工项(工件)来显示彼此之间的关系，用状态表显示每个加工项(工件)在特定时间的完成情况。

过程的元素：

1. 活动：过程中要发生的事件。各种前后关系、触发条件、规则、团队成员等等。也可以理解为子过程。
2. 序列：活动顺序等等。
3. 过程模型：小型工程可以认为是开发方式等描述。
4. 资源：活动所需的各种资源标注。
5. 控制：针对活动的外部影响等。
6. 策略：各种指导原则，包括约束等。
7. 组织：各种层次化结构等描述。包括物理的和软件逻辑的结构。

动态建模

推演一个过程，用户和开发人员可以看到中间产品和最终产品如何随着时间的推移进行转换。

系统动力学：展示资源流(非一般性输入)如何通过活动成为输出。

在所有的软件开发过程模型中，你认为哪些过程给予你最大的灵活性以应对需求的变更？

1. 设计对于分析模型应该是可跟踪的：软件的模块可能被映射到多个需求上。
2. 设计结构应当尽可能的模拟实际问题。
3. 设计应当表现出一致性。
4. 不要把设计当成编写代码。
5. 在创建设计时就应该能够评估质量。