系统架构15 - 软件工程（3）

软件过程模型是一种规划和组织软件开发过程的方法。
过程模型通常由一系列阶段和任务组成，这些任务在软件开发的不同阶段都有特定的目标。每个阶段都有自己的任务和产出物，这些产出物构成了软件开发的不同部分，最终汇总成完整的软件产品。

瀑布模型

瀑布模型 (Waterfall Model) 是最早使用的软件过程模型之一，包含一系列活动。这些活动从一个阶段到另一个阶段逐次下降，它的工作流程在形式上很像瀑布，因此被称为瀑布模型。

特点

• 因果关系紧密相连，前一个阶段工作的输出结果，是后一个阶段工作的输入。
• 每一个阶段都是建筑在前一个阶段正确实施的结果之上。
• 每一个阶段工作完成后都伴随着一个里程碑(一组检查条件)，对该阶段的工作进行审查和确认。

缺点

（1）软件需求的完整性、正确性等很难确定，甚至是不可能和不现实的。
（2）瀑布模型是一个严格串行化的过程模型，使得用户和软件项目负责人要相当长的时间才能得到一个可以看得见的软件系统。
（3）瀑布模型的基本原则是在每个阶段一次性地完全解决该阶段的工作，不会出现遗漏、错误等情况，而实际上这是不现实、不可能的。

原型化模型

原型模型 (Prototype Model) 又称快速原型。
由于瀑布型的缺点，人们借鉴建筑师、工程师建造原型的经验，提出了原型模型。

特点

创建快速原型，弄清当前需求。
适用于需求不明确的情况。

两个阶段

1. 原型开发阶段。软件开发人员根据用户提出的软件系统的定义，快速地开发一个原型。该原型应该包含目标系统的关键问题和反映目标系统的大致面貌，展示目标系统的全部或部分功能、性能等。
2. 目标软件开发阶段。在征求用户对原型的意见后对原型进行修改完善，确认软件系统的需求并达到一致的理解，进一步开发实际系统。

不同类型

按照原型的作用不同，分为抛弃型原型和演化性原型。
（1）抛弃型原型是将原型作为需求确认的手段，在需求确认结束后，原型就被抛弃不用，重新采用一个完整的瀑布模型进行开发。
（2）演化性原型是在需求确认结束后，不断补充和完善原型，直至
形成一个完整的产品。

注意

• 用户对系统的认识模糊不清，无法准确回答目标系统的需求。
• 要有一定的开发环境和工具支持。
• 经过对原型的若干次修改，应收敛到目标范围内，否则可能会失败。
• 对大型软件来说，原型可能非常复杂而难以快速形成，如果没有现成的原型模型，就不应考虑用原型法。

螺旋模型

螺旋模型 (Spiral Model) 是在快速原型的基础上扩展而成。也有人把螺旋模型归到快速原型，实际上，它是生命周期模型与原型模型的结合。

这种模型把整个软件开发流程分成多个阶段，每一个阶段都由4部分组成：
（1）目标设定。为该项目进行需求分析，定义和确定这一个阶段的专门目标，指定对过程和产品的约束，并且制订详细的管理计划。
（2）风险分析。对可选方案进行风险识别和详细分析，制定解决办法，采取有效措施避免这些风险。
（3）开发和有效性验证。风险评估后，可以为系统选择开发模型，并且进行原型开发，即开发软件产品。
（4）评审。对项目进行评审，以确定是否需要进入螺旋线的下一次回路，如果决定继续，就要制订下一阶段计划。

该模型支持大型软件开发，适用于面向规格说明、面向过程和面向对象的软件开发方法，也适用于几种开发方法的组合。

V 模型

从整体上看，V模型就是一个V字结构。
由左右两边组成，如下图。

特点

• 单元测试的主要目的是针对编码过程中可能存在的各种错误；
• 集成测试主要针对详细设计中可能存在的问题；
• 系统测试主要针对概要设计，检查系统作为一个整体是否有效得到运行；
• 验收测试通常由业务或专家或用户来进行，以确认产品能真正符合用户业务上的需要。
• V模型适用于需求明确并且需求变更不频繁的情形。

增量模型

首先开发核心模块功能，而后与用户确认，之后再开发次核心模块的功能。
即，每次开发一部分功能，并与用户确认，最终完成项目开发，优先级最高的服务最先交付。

特点

但由于并不是从系统整体角度规划各个模块，所以并不利于模块划分。
难点在于如何将用户需求划分为多个增量。
与原型不同的是，增量模型的每一次增量版本都可以作为独立可操作的产品；而原型的构造一般是为了演示。

喷泉模型

是一种以用户需求作为动力，以对象作为驱动的模型，适合于面向对象开发方法。

基于构件的开发模型(CBSD)

也称为快速开发模型。
主要是利用预先包装的构件来构造应用系统。
构件可以是组织内部开发的构件，也可以是商品化成品软件构件。
特点是增强了复用性。
在开发过程中，会构建一个构件库，供其它系统复用，因此可以提高可靠性，节省时间和成本。

形式化方法模型

建立在严格数学基础上的一种软件开发方法。
主要活动是生成计算机软件形式化的数学规格说明。

敏捷模型

软件开发在20世纪90年代受到两个大的因素影响：

1. 对内，面向对象编程开始取代面向过程编程；
2. 对外，互联网泡沫导致快速投向市场以及公司的快速发展成为关键商业因素。

快速变化的需求需要短的产品交付周期，这与传统软件开发流程并不兼容。
2001年2月，17位著名的软件开发专家举行了一次敏捷方法发起者和实践者的聚会。在这次会议上，正式提出了Agile (敏捷)的概念。

特点

敏捷型方法主要有两个特点，这也是其区别于其他方法——尤其是计划驱动或重型开发方法——的最主要的特征。

“适应性” (adaptive) 而非“预设性” (predictive)

软件开发不同于传统工程——如土木工程等——无法将设计和实施分离开来。
一些设计错误只能在编码和测试时才能发现，根本无法做出一个交给程序员就能直接编码的软件设计。
软件需求的不稳定，导致软件过程的不可预测。
但是，必须对这样的过程进行监控，以使得整个过程能向期望的目标前进。
敏捷方法使用反馈机制对不可预测过程进行控制。

“面向人的” (People-oriented) 而非“面向过程的” (Process-oriented)

• 敏捷开发过程要求开发人员必须有权做技术方面的所有决定。开发人员和管理人员在一个软件项目的领导方面有同等的地位，共同对整个开发过程负责。
• 敏捷方法特别强调开发中相关人员之间的信息交流。项目的需求是在不断变化的，管理人员之间、开发人员之间以及管理人员和开发人员之间，都必须不断地了解这些变化，对这些变化做出反应，并实施在随后的开发过程中。
• 敏捷方法还特别提倡直接的面对面交流。一般都按照高内聚、低耦合的原则将项目划分为若干小组，以增加沟通，提高敏捷性及应变能力。

核心思想

1. 敏捷方法是适应型，而非可预测型。与传统方法不同，敏捷方法拥抱变化，也可以说它的初衷就是适应变化的需求，利用变化来发展，甚至改变自己，最后完善自己。
2. 敏捷方法是以人为本，而非以过程为本。强调充分发挥人的特性，不去限制它。并且软件开发在无过程控制和过于严格烦琐的过程控制中取得一种平衡，以保证软件的质量。
3. 迭代增量式的开发过程。敏捷方法以原型开发思想为基础，采用迭代增量式开发，发行版本小型化。它根据客户需求的优先级和开发风险，制订版本发行计划，每一发行版都是在前一成功发行版的基础上进行功能需求扩充，最后满足客户的所有功能需求。

主要敏捷方法

极限编程（XP）

极限编程 (Extreme Programming,XP)。
在所有的敏捷型方法中， XP是最引人瞩目的。
极限编程是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。
它的基础和价值观是交流、朴素、反馈和勇气，即任何一个软件项目都可以从4个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。

特点

1. XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其他一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程；
2. XP提倡测试先行，目的是将以后出现BUG的几率降至最低。

水晶系列方法

水晶系列方法(Crystal)与XP方法一样，都有以人为中心的理念，但在实践上有所不同。
其目的是发展一种提倡“机动性的”方法，包含具有共性的核心元素，每个都含有独特的角色、过程模式、工作产品和实践。
Crystal 家族实际上是一组经过证明、对不同类型项目非常有效的敏捷过程，它的发明使得敏捷团队可以根据其项目和环境选择最合适的 Crystal 家族成员。

并列争球法(Scrum)

并列争球法(Scrum)侧重于项目管理。
Scrum是迭代式增量软件开发过程，通常用于敏捷软件开发。 Scrum包括了一系列实践和预定义角色的过程骨架(是一种流程、计划、模式，用于有效率地开发软件)。
在Scrum 中，使用产品 Backlog 来管理产品的需求。
产品 Backlog 是一个按照商业价值排序的需求列表。
根据 Backlog 的内容，将整个开发过程被分为若干个短的迭代周期 (Sprint)。
在 Sprint 中，Scrum 团队从产品 Backlog 中挑选最高优先级的需求组成 Sprint backlog。
在每个迭代结束时， Scrum 团队将递交潜在可交付的产品增量。
当所有 Sprint 结束时，团队提交最终的软件产品。

特征驱动开发方法(FDD)

特征驱动开发方法 (Feature Driven Development,FDD) 是一个迭代的开发模型。 FDD认为有效的软件开发需要3个要素：人、过程和技术。

项目角色

FDD定义了6种关键的项目角色：
（1）项目经理
（2）首席架构设计师
（3）开发经理
（4）主程序员
（5）程序员
（6）领域专家。
根据项目大小，部分角色可以重复。

核心过程

（1）开发整体对象模型
（2）构造特征列表
（3）计划特征开发
（4）特征设计
（5）特征构建。
其中，计划特征开发根据构造出的特征列表、特征间的依赖关系进行计划，设计出包含特征设计和特征构建过程组成的多次迭代。

统一过程模型(RUP)

软件统一过程 (Rational Unified Process, RUP) 描述了如何有效地利用商业的、可靠的方法开发和部署软件，是一种重量级过程。
RUP类似一个在线的指导者，它可以为所有方面和层次的程序开发提供指导方针、模版以及事例支持。

生命周期阶段

核心工作流

RUP 软件开发生命周期是一个二维的软件开发模型，RUP 中有9个核心工作流，具体如下。

• 业务建模 (Business Modeling)：理解待开发系统所在的机构及其商业运作，确保所有参与人员对待开发系统所在的机构有共同的认识，评估待开发系统对所在机构的影响。
• 需求(Requirements)：定义系统功能及用户界面，使客户知道系统的功能，使开发人员理解系统的需求，为项目预算及计划提供基础。
• 分析与设计 (Analysis & Dcsign)：把需求分析的结果转化为分析与设计模型。
• 实现 (Implementation)：把设计模型转换为实现结果，对开发的代码做单元测试，将不同实现人员开发的模块集成为可执行系统。
• 测试 (Test)：检查各子系统之间的交互、集成，验证所有需求是否均被正确实现，对发现的软件质量上的缺陷进行归档，对软件质量提出改进建议。
• 部署 (Deployment)：打包、分发、安装软件，升级旧系统；培训用户及销售人员，并提供技术支持。
• 配置与变更管理 (Configuration & Change Management)：跟踪并维护系统开发过程中产生的所有制品的完整性和一致性。
• 项目管理 (Project Management)：为软件开发项目提供计划、人员分配、执行、监控等方面的指导，为风险管理提供框架。
• 环境 (Environment)：为软件开发机构提供软件开发环境，即提供过程管理和工具的支持。

表示核心工作流的术语 Discipline，中文意义较多。根据RUP的定义，Discipline是相关活动的集合，这些活动都和项目的某一个方面有关，如这些活动都是和业务建模相关的，或者都是和需求相关的，或者都是和分析设计相关的，等等。

循环中的阶段

RUP 把软件开发生命周期划分为多个循环 (Cycle)，每个循环生成产品的一个新的版本，每个循环依次由4个连续的阶段 (Phase) 组成，每个阶段完成确定的任务。

• 初始 (inception) 阶段：定义最终产品视图和业务模型，并确定系统范围。
• 细化 (elaboration) 阶段：设计及确定系统的体系结构，制订工作计划及资源要求。
• 构造 (construction) 阶段：构造产品并继续演进需求、体系结构、计划直至产品提交。
• 移交 (transition) 阶段：把产品提交给用户使用。

每一个阶段都由一个或多个连续的迭代 (Iteration) 组成。
迭代并不是重复地做相同的事，而是针对不同用例的细化和实现。
每一个迭代都是一个完整的开发过程，它需要项目经理根据当前迭代所处的阶段以及上次迭代的结果，适当地对核心工作流中的行为进行裁剪。
在每个阶段结束前有一个里程碑 (Milestone) 评估该阶段的工作。如果未能通过该里程碑的评估，则决策者应该做出决定，是取消该项目还是继续做该阶段的工作。

核心概念

RUP 中定义了如下一些核心概念，理解这些概念对于理解RUP很有帮助。

• 角色 (Role)：Who 的问题。角色描述某个人或一个小组的行为与职责。 RUP预先定义了很多角色，如体系结构师 (Architect)、 设计人员 (Designer)、 实现人员(Implementer)、 测试员 (tester) 和配置管理人员 (Configuration Manager) 等，并对每一个角色的工作和职责都做了详尽的说明。
• 活动 (Activity)：How 的问题。活动是一个有明确目的的独立工作单元。
• 制品(Artifact)：What 的问题。制品是活动生成、创建或修改的一段信息。也有些书把 Artifact 翻译为产品、工件等，和制品的意思差不多。
• 工作流 (Workflow)：When 的问题。工作流描述了一个有意义的连续的活动序列，每个工作流产生一些有价值的产品，并显示了角色之间的关系。

RUP 2003对这些概念有比较详细的解释，并用类图描述了这些概念之间的关系，除了上述这4个核心概念外，还有其他一些基本概念，如工具教程 (ToolMentor)、 检查点 (Checkpoints)、 模板 (Template) 和报告 (Report) 等。

特点

RUP 是用例驱动的、以体系结构为中心的、迭代和增量的软件开发过程。

用例驱动

RUP中的开发活动是用例驱动的，即需求分析、设计、实现和测试等活动都是用例驱动的。

以体系结构为中心

RUP中的开发活动是围绕体系结构展开的。
软件体系结构的设计和代码设计无关，也不依赖于具体的程序设计语言。
软件体系结构是软件设计过程中的一个层次，这一层次超越计算过程中的算法设计和数据结构设计。
体系结构层次的设计问题包括系统的总体组织和全局控制、通信协议、同步、数据存取、给设计元素分配功能、设计元素的组织、物理分布、系统的伸缩性和性能等。
对于一个软件系统，不同人员所关心的内容是不一样的。
因此，软件的体系结构是一个多维的结构，也就是说，会采用**多个视图 **(View) 来描述软件体系结构。
RUP采用“4+1”视图模型来描述软件系统的体系结构，如下图所示。

迭代与增量

RUP强调采用迭代和增量的方式来开发软件，把整个项目开发分为多个迭代过程。
在每次迭代中，只考虑系统的一部分需求，进行分析、设计、实现、测试和部署等过程。
每次迭代是在已完成部分的基础上进行的，每次增加一些新的功能实现。
以此进行下去，直至最后项目的完成。
软件开发采用迭代和增量的方式有以下几种优点：
（1）在软件开发的早期就可以对关键的、影响大的风险进行处理。
（2）可以提出一个软件体系结构来指导开发。
（3）可以更好地处理不可避免的需求变更。
（4）可以较早得到一个可运行的系统，鼓舞发团队的士气，增强项目成功的信心。
（5）为开发人员提供一个能更有效工作的开发过程。