瀑布模型

瀑布模型是将开发活动分解为线性顺序阶段的细分,这意味着它们相互传递,每个阶段都取决于上一个的可交付成果,并且对应于任务的专业化。该方法对于工程设计的某些领域是典型的。在软件开发中,它往往是迭代和灵活的方法之一,因为进步在很大程度上流动(像瀑布一样向下”,通过构思,启动,分析,设计,设计,构造,测试测试部署维护的阶段。 。瀑布模型是软件开发中使用的最早的SDLC方法。

瀑布发展模型起源于制造业建筑行业,在该行业中,高度结构化的物理环境意味着设计变化在开发过程中变得非常昂贵。当首次用于软件开发时,没有公认的基于知识的创意工作的替代方法。

历史

赫伯特·贝宁顿(Herbert D. Benington)于1956年6月29日在数字计算机的高级编程方法研讨会上举行了描述此类阶段在软件工程中使用此类阶段的第一个已知介绍。该演示文稿是关于Sage软件的开发。 1983年,本宁顿(Benington)的前言重新出版了该论文,解释说,根据任务的专业化,该阶段是有目的的,并指出该过程实际上并非以严格的自上而下的方式进行,但取决于原型。

尽管本文中未使用“瀑布”一词,但该过程的第一个正式详细图表后来称为“瀑布模型”,通常被温斯顿·罗伊斯(Winston W. Royce)称为1970年的文章。然而,他也认为这是由于测试仅在过程结束时进行的,这是一个重大缺陷,他形容这是“冒险并引起失败”。他的其余论文提出了五个步骤,他认为这是“消除与不变的瀑布方法相关的大多数发展风险”所必需的。

罗伊斯(Royce)的另外五个步骤(包括在发展的各个阶段编写完整的文档)从未占主流,但是他所认为的有缺陷过程的图成为描述“瀑布”方法的起点。

最早使用“瀑布”一词可能是在贝尔和泰耶(Bell and Thayer)的1976年论文中。

1985年,美国国防部DOD-STD-2167A中捕获了这种方法,他们与软件开发承包商合作的标准说:“承包商应实施一个软件开发周期,其中包括以下六个阶段:软件需求分析,初步设计,详细的设计,编码和单元测试,集成和测试”。

模型

尽管罗伊斯(Royce)从未推荐或描述过瀑布模型,但对以下阶段的严格遵守受到他的批评:

  1. 系统软件要求:在产品需求文件中捕获
  2. 分析:导致模型模式业务规则
  3. 设计:导致软件体系结构
  4. 编码:软件的开发证明集成
  5. 测试:系统发现和调试缺陷
  6. 操作:完整系统的安装迁移支持维护

因此,瀑布模型坚持认为,只有在审查和验证其前阶段时才应移动到一个阶段。

但是,各种修改的瀑布模型(包括Royce的最终模型)可能包括此过程的微小或主要变化。这些变化包括在下游发现缺陷后返回到上一个周期,或者如果认为不足的下游阶段,则一直返回到设计阶段。

支持参数

在软件生产周期中花费的时间可以降低以后阶段的成本。例如,在早期阶段发现的问题(例如需求规范)比后来在此过程中发现的错误(以50至200倍)便宜。

在常规实践中,瀑布方法学会导致项目时间表,在前两个阶段投入了20-40%的时间,30-40%的时间进行编码,其余时间则用于测试和实施。实际的项目组织需要高度结构化。大多数中型项目和大型项目都将包括一组详细的程序和控件,这些程序和控件都规范了项目的每个过程。

瀑布模型的另一个论点是,它强调文档(例如需求文档和设计文档)以及源代码。在较不彻底的设计和记录的方法中,如果团队成员在项目完成之前离开,知识就会丢失,并且项目可能很难从损失中恢复过来。如果存在一个完全有效的设计文档(以及前面大型设计的意图和瀑布模型的意图),那么新的团队成员甚至全新的团队都应该能够通过阅读文档来熟悉自己。

瀑布模型提供了一种结构化方法。该模型本身通过离散,易于理解和可解释的阶段进行线性发展,因此很容易理解。它还在开发过程中提供了易于识别的里程碑。也许是出于这个原因,将瀑布模型用作许多软件工程文本和课程中开发模型的开头示例。

模拟可以在瀑布模型中起宝贵的作用。通过对正在开发的系统进行计算机化或数学模拟,团队可以洞悉系统在继续下一阶段之前的性能。模拟允许测试和完善设计,识别潜在的问题或瓶颈,并就系统的功能和性能做出明智的决定。

批评

客户可能在查看工作软件之前可能不知道他们的要求是什么,因此可以更改其要求,从而导致重新设计,重新开发和重新测试以及增加成本。

设计人员在设计新的软件产品或功能时可能不会意识到未来的困难,在这种情况下,修改设计要比坚持不考虑任何新发现的约束,需求或问题的设计要好。

组织可能会尝试通过使用系统分析师来检查现有的手动系统并分析他们的工作以及如何更换他们的方式来应对客户缺乏具体的要求。但是,实际上,很难在系统分析和编程之间进行严格的分离。这是因为实施任何非平凡系统几乎不可避免地会暴露系统分析师没有考虑的问题和边缘案例。

为了应对瀑布模型的感知问题,引入了修改的瀑布模型,例如“生鱼片(具有重叠阶段的瀑布),带有次要的瀑布以及降低风险的瀑布”。

一些组织,例如美国国防部现在对瀑布型方法的偏爱,从1994年发布的MIL-STD-498开始,这鼓励了进化的收购以及迭代和迭代和增量发展

修改的瀑布模型

为了应对“纯”瀑布模型的感知问题,已经引入了许多“修改后的瀑布模型”。这些模型可能会解决“纯”瀑布模型的某些或全部批评。

其中包括史蒂夫·麦康奈尔(Steve McConnell )称之为“修改后的瀑布”的快速开发模型:彼得·德格拉斯(Peter Degrace)的“生鱼片”模型(带有重叠阶段的瀑布),带有次要身影的瀑布以及降低风险的瀑布。还存在其他软件开发模型组合,例如“增量瀑布模型”。

罗伊斯的最终模型

Royce最终模型

温斯顿·罗伊斯(Winston W.设计回到要求规范(由于设计问题可能需要删除冲突或其他不满意/不可避免的要求)。罗伊斯(Royce)在同一篇论文中还提倡大量文档,以“如果可能的话”完成这项工作(与弗雷德·布鲁克斯(Fred Brooks)类似的情绪,以撰写神话人物月份而闻名,这是一本有影响力的软件项目管理书籍,他倡导计划计划,以提倡计划计划“扔掉”),并尽可能多地参与客户(类似于极端编程的情感)。

Royce关于最终模型的注释是:

  1. 在分析和编码开始之前完成程序设计
  2. 文档必须是最新的,并且必须完成
  3. 尽可能完成两次工作
  4. 必须计划,控制和监视测试
  5. 参与客户

也可以看看