软件开发各种模型.docx

瀑布模型 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 （ Rational Unified Process，统一软件开发过程，统一软件过 程）推荐的周期模型。在 RUP中，迭代被定义为：迭代包括产生产品发布（稳定、可 执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。所以， 在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求 工作流程、分析设计工作流程、实施工作流程和测试工作流程。 实质上，它类似小型的瀑布式项目。 RUP认为，所有的阶段（需求及其它）都 可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品 的一个子集。迭代的思想如图所示。 需求 业务工理 在现代过程方法 XP （ extreme Programming ，极限编程）、RUP无一例外地都 推荐、主张采用能显著减少风险的迭代模型。美国国防部原本提倡瀑布过程和观点， 在发现那么多采用了 瀑布模型的失败的项目之后，不但放弃了对它的要求，而且从 1 994年的报告开始，积极地鼓励采用更加现代化的迭代模型来取代瀑布模型做法。同 时，中国中科院也提倡选用迭代模型。 对众多的开发模型和过程方法，及权威机构的看法，企业应选择什么样的开发模 型