常用的软件开发模型任务的结构框 架。

软件开发包括需求、设 段。

软件开发 模型能清晰、直观地表达软 计、编码和测试等阶段，有 时也包括维护阶件开发全过程，明确规定了 要完成的主要活动和任务，用来作为软 件项目工作的基础。

对于不同的软件 系统，可以采用不同的开理方法和手段 等，以及允许采用不同的软件工 具和不同的软件工程环境。

1. 瀑布模型 -最早出现的软件开发模型1970 年温斯顿 ?罗伊斯( Winston Royce )提出了著名的 “瀑布模型 ”，直到 80 年 代早期，它一 直是唯一被广泛采用的软件开发 模型。

瀑布模型 核心思想是按工序将问题化简 ，将功能的实现与设计分开 ，便于分工协 作，即采 用结构化的分析与设计方法将逻 辑实现与物理实现分开。

将 软件生命周期划 分为制定计划 、需求分析、软件设计、程序编写、软件测试和运行维 护等六个基本活 动，并 且规定了它们自上而下 、相互衔接的固定次序 ，如同瀑布流水，逐级 下落。

从 本质来讲，它是一个软 件开发架构，开发过程是通过一系列 阶段顺序展开的，从系统 需求分析开始 直到产品发布和维护，每个阶段都会产 生循环反馈，因此，如果有信息 未被覆盖或者 发现了问题， 那么 最好 “返回 ”上一个 阶段并进行适当的修改 ，开发进程 从一个阶段 “流动 ”到下一个阶段， 这也是瀑布开发名称的由来。

瀑布模型是最 早出现的软件开发模型，在软件工程中占有重要的地位 ，它提供了 软件开发的基 本框架。

其过程是从上一项 活动接收该项活动的工作对象作 为输入，利 用这一输入实 施该项活动应完成的内容给出该 项活动的工作成果， 并 作为输出传给下 一项活动。

同 时评审该项活动的实施，若确认 ，则继续下一项活动；否则返 回前面， 甚至更前面的 活动。

对于经常变化的项目而 言，瀑布模型毫无价值。

(采用瀑布模型 的软件过程如 图所示)软件 开发模型 (Software DevelopmentModel) 是指软件开发 全部过程、活动和 发方法、使用不同的程序设计语言以及各种不同技能的人员参与工作 、运用不同的管瀑布模型的客户需求尽管瀑布 模型招致了很多批评，但是 它对很多类型的项目而言依然是有效的，如果正确使用，可以节省大量的时间和金钱。

对于您的项目而言，是否使用这一模型主要取决于您是 否能理解客户的需求以及在项目 的进程中这些需求的变化程度，对于经常变化的项目 而言，瀑布模型毫无价值，对于这种情况，您可以考虑 其他的架构来进行项目管理，比如名为螺旋模型（ spiral model ）的方法。

在瀑布模 型中，软件开发的各项活动 严格按照线性方式进行，当前活动接受上一项活动的工作 结果，实施完成所需的工作内容 。

当前活动的工作结果需要进行验证，如果验证通过，则该结 果作为下一项活动的输入，继续进行 下一项活动，否则返回修改。

瀑布模型 强调文档的作用，并要求每个阶段都要 仔细验证。

但是，这种模型的线性过程太理想 化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在用户要求瀑布模型的优缺点1、瀑布模型有以下优点: 1） 为项目提供了按阶段划分的 2） 当前一阶段完成后，您只需 3 ）可在迭代模型中应用瀑布模 检查点。

要去关注后续阶段。

型。

增量迭代应用于瀑布模型。

迭代 1解决最大的问题。

每次迭代产 生一个可运行的版本，同时增加更多的功能。

每次2、瀑布模型有以下缺点： 1） 在项目各个阶段之间极少有 2） 只有在项目生命周期的后期3） 通过过多的强制完成日期和迭代必须经过质量和集成测试。

反馈。

才能看到结果。

里程碑来跟踪各个项目阶段。

于：量;（2） 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果 从而增加了开发的风险；（3） 早期的错误可能要等到开发后期的 测试阶段才能发现，进 而带来严重的后 果。

按照瀑布模型 的阶段划分，软件测试可以分为单元测试，集成测试，系统测 试。

2. 迭代模型早在20世纪50年代末期，软件领域中就出现了迭 代模型。

最早的迭代过程可能 被描述为 分段模型（stagewise model ） ”，其背景是 H.D.Benington 领导的美国空 军SAGE 项目。

迭代模型是 RUP （ Rational Unified Process ，统一软件开发过程，统一软件过 程）推荐的 周期模型。

在 RUP 中，迭代被定义为：迭代包括产生产品 发布（稳定、可的一个子集。

迭代的思想如图所示。

需求在现代过程方法 XP （ eXtreme Programming ，极限编程）、 RUP 无一例外地都推荐、主张采用能显著减少风险的迭代模型。

美国国防部原本提倡瀑布过程 和观点，在发现那么多 采用了瀑布模型的失败的项目之 后，不但放弃了对它的要求，而且从1994年的报告开始，积极地鼓励采用更加现代化的迭代模型来取 代瀑布模型做法。

同时，中国中科 院也提倡选用迭代模型。

对众多的 开发模型和过程方法，及权 威机构的看法，企业应选择什么样的开发模型，应慎重对 从以下几方面进行考虑：执行的产品版本）的全部开发活动和要使用该 在某种程度上，开发迭代是一次完整地经过 工作流程、分 析设计工作流程、实施工作流程发布必需的所有其他外围元素 。

所以, 所有工作流程的过程：（至 少包括）需求和测试工作流程。

实质上，它类 似小型的瀑布式项目。

可以细分为迭代。

每一次的迭代都会产生 RUP 认为，所有 的阶段（需求及其它）都 一个可以发布的产品，这个产品是最终产品1 、 RUP 虽然内容极其丰 富，定义了选起 、精化 、构建、产品化 4 个阶段和业务 建模、需求、 分析设计、实现、测试、部署等9 个工 种，提供了一大堆的文档模板 但极易让人误 解是重型的过程，实施推广有一定难度。

2 、再次，在质量管理方面：以 实现系统架构、核心功能目标的 迭代产品生的工 作成果作为质 量控制重点。

每次迭代进行系统集成、系统测 试，达到对软件质量的持 续验证。

每次系统测试，需要 回归测试前一次迭代遗留发现 的问题。

每次迭代发布的 小版本组织客 户（包括内部客户 、外部客户）进行评 价，通过演示操作等方 式，评价 该次迭代是否 达到预定的目标，并以此为依据 来制定下一次迭代的目标。

3 、最后，在其他方面：每次迭 代成果须进行配置管理，版本控 制很重要。

在整 个迭代过程中 风险无处不在，建议每周作一次风险跟 踪。

同时通过重点关注进度、工 作量、满意度 、缺陷等数据收集，关注每次迭 代情况。

总之，选择一个合 适的生命周期模型，并应用正确的方 法，对于任何软件项目的 成功是至关重 要。

企业在选择开发模型应从项目时间 要求、需求明确程度、风险状况 等选择合适的 生命周期模型。

迭代模型的选择使用条件所变化。

熟悉。

项目的开发过程。

建模语言 （ Unified Modeling Language ，UML ）。

6 、使用 CASE （ Computer Aided Software Engineering ，计算机辅助软件工 程）工具，如 Rose （ Rose 是非常受欢迎的物件软 体开发工具。

）。

7 、具有高素质的项目管理者和 软件研发团队。

迭代模型的优点与传统的 瀑布模型相比较，迭代过程具有 以下优点：1 ）降低了在一个增量上的开支 风险。

如果开发人员重复某个迭 代，那么损失只 是这一个开发 有误的迭代的花费。

2）降低 了产品无法按照既定进度进入市 场的风险。

通过在开发早期就确定风险可以尽早来解 决而不至于在开发后期匆匆忙忙 。

3 ）加快了整个开发工作的进度 。

因为开发人员清楚问题的焦点 所在，他们的工 作会更有效率 。

4 ）由于用 户的需求并不 能在一开始就 作出完全的界 定，它们通常 是在后续 阶段中不断细化的。

因此，迭代过程这种模式 使适应需求的变化会更容易些 。

3. 螺旋模型1 、在项目开发早期需求可能有2 、分析设计人员对应用领域很3 、高风险项目。

4 、用户可不同程度地参与整个5 、使用面向对象的语言或统一"螺旋模型”，它将瀑布模型和快速 特别适合于大型复杂的系统 。

1988年，BarryBoehm 正式发表了软件系统开发的 原型模型结合起来，强调了其他模型所忽视的风险分析， 螺旋模型 沿着螺线进行若干次迭代，图中 的四个象限代表了以下活动:（1 ） (2) (3) 制定计划：确定软件目标 风险分析：分析评估所选 实施工程：实施软件开发 客户评估：评价开发工作 ，选定实施方案，弄清项目开发 方案，考虑如何识别和消除风险 和验证； ，提出修正建议，制定下一步计 的限制条件;（4） 螺旋模型由风险驱动，强调可选方案 软件质量作为 特殊目标融入产品开发之中。

但是， 体如下： （1 ）螺旋模型强调风险分 析，但要求许 关反应是不容 易的，因此，这种模型往往适应 （2 ）如果执行风险分析将 大大影响项目 因此，螺旋模 型只适合于大规模软件项目。

（3 ）软件开发人员应该擅 长寻找可能的 更大的风险 一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约 后从风险角度分析方案的开发策略，努力 型来完成。

如果某些风险不能排除，该方 后，评价该阶 螺旋模型 很难让用 划。

和约束条件从而支持软件的重用 ，有助于将 螺旋模型 也有一定的限制条件，具 多客户接受和 相信这种分析， 并做出相 于内部的大规模软件开发。

的利润，那么 进行风险分析毫 无意义， 风险，准确地 分析风险，否则 将会带来展比较快，所以经常出 满足当前用户需求。

排除各种潜在的风险，有时 案立即终止，否则启动下一个 段的结果，并设计下一个阶段。

的缺点： 户确信这种演化方法的结果是可 以控制的。

建设周期长 现软件开发完毕后，和当前的技术水 束条件，然 需要通过建造原 开发步骤。

最 ，而软件技术发 平有了较大的差距，无法螺旋模型的项目适用：对于新近开发，需求不明确的情况下，适合用螺旋模型进行开发，便于风险控制和需求变更！4.变换模型变换模型是基于形式化规格说明语言及程序变换的软件开发模型，它采用形式化的软件开发方法对形式化的软件规格说明进行一系列自动或半自动的程序变换，最后映射为计算机系统能够接受的程序系统。

采用变换模型的软件过程如图1-5所示。

图1-5 采用变换模型的软件过程为了确认形式化规格说明与软件需求的一致性，往往以形式化规格说明为基础开发一个软件原型，用户可以从人机界面、系统主要功能和性能等几个方面对原型进行评审。

必要时，可以修改软件需求、形式化规格说明和原型，直至原型被确认为止。

这时软件开发人员即可对形式化的规格说明进行一系列的程序变换，直至生成计算机系统可以接受的目标代码。