软件开发各种模型参照.pdfVIP

瀑布模型 1970 年温斯顿 ?罗伊斯（ Winston Royce ）提出了著名的 瀑布模型“ ”，直到 80 年 代早期，它一直是唯一被广泛采用的 软件开发模型 。 瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协 作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将 软件生命周期 划 分为制定计划、需求分析、软件设计、程序编写、 软件测试 和运行维护等六个基本活 动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。从 本质来讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从系统 需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息 未被覆盖或者发现了问题， 那么最好 “返回 ”上一个阶段并进行适当的修改， 开发进程 从一个阶段 “流动 ”到下一个阶段，这也是瀑布开发名称的由来。 瀑布模型是最早出现的软件开发模型，在 软件工程 中占有重要的地位，它提供了 软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利 用这一输入实施该项活动应完成的内容给出该项活动的工作成果， 并作为输出传给下 一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面， 甚至更前面的活动。对于经常变化的项目而言，瀑布模型毫无价值。（采用瀑布模型 的软件过程如图所示） 瀑布模型的优缺点 1 、瀑布模型有以下优点： 1 ）为项目提供了按阶段划分的检查点。 2 ）当前一阶段完成后，您只需要去关注后续阶段。 3 ）可在 迭代模型 中应用瀑布模型。 增量迭代应用于瀑布模型。迭代 1 解决最大的问题。每次迭代产生一个可运行的 版本 , 同时增加更多的功能。每次迭代必须经过质量和集成测试。 2 、瀑布模型有以下缺点： 1 ）在项目各个阶段之间极少有反馈。 2 ）只有在项目生命周期的后期才能看到结果。 3 ）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。 瀑布模型的客户需求 尽管瀑布模型招致了很多批评，但是它对很多类型的项目而言依然是有效的，如 果正确使用，可以节省大量的时间和金钱。对于您的项目而言，是否使用这一模型主 要取决于您是否能理解客户的需求以及在项目的进程中这些需求的变化程度， 对于经 常变化的项目而言，瀑布模型毫无价值，对于这种情况，您可以考虑其他的架构来进 行项目管理，比如名为 螺旋模型 （spiral model ）的方法。 在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一 项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证， 如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修 改。 瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线 性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在 于： （1 ） 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作 量； （2 ） 由于开发模型是线性的， 用户只有等到整个过程的末期才能见到开发成果， 从而增加了开发的风险； （3 ） 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后 果。 按照瀑布模型的阶段划分，软件测试可以分为单元测试，集成测试，系统测试。 迭代模型 早在 20 世纪 50 年代末期， 软件 领域中就出现了迭代模型。 最早的迭代过程可能 被描述为 “分段模型（ stagewise model ） ”，其背景是 H.D.Benington 领导的美国空 军 SAGE 项目。 迭代模型是 RUP （Ration