这是我的解释，但我试图提供给我使用的所有源材料的链接，以便如果您不同意我的结论，您可以完成自己的研究。
这是这个维基文章的第5个主要版本，我认为提供了一些介绍，以及为什么我写的（和偶尔更新）这么长的文章有关瀑布这样的“独裁者”方法。
几年前，我的雇主开始努力正式采用一些敏捷进程（当时的Scrum，Dad目前）对于某些项目类型。想要更多地教育自己，我开始做谷歌搜索并阅读我能找到的材料。但是，我的阅读被劫持，因为我一遍又一遍地遇到了“瀑布”的描述，这一遍又一次地与我们在雇主那样不匹配，或者我所谈论的任何其他BA所说的方式描述了他们所做的项目。
所以我很好奇。我的雇主是否采用了一些“改进”版本的瀑布，这不是那么僵硬吗？实际上有人在那里倡导普遍的瀑布形式，我一直在阅读'敏捷的网站上阅读吗？如果是这样，他们的逻辑是什么，我可以从中学到什么？
所以我开始研究瀑布。我发现它据说它在互联网上挖出了原始纸张（我在下面深入讨论的royce纸）。令人惊讶的是，它几乎没有任何内容与我在敏捷网站上阅读的刚性过程中的任何内容。
所以我开始研究更多，我惊讶地开始跨越罗伊斯纸的研究论文，但这完全错误地表征了它所说的。这些是在学术期刊上发表的论文，而不是一些随机博客，所以你会期待更高的质量。所以我研究了越来越多;对我有什么着迷的是人们一直被称为“瀑布”的二分法，并且实际上发表的是被称为瀑布方法的主要“来源”。
因此，本文出生就“瀑布”。这不是“道歉”或“防守”的瀑布。这是我最大的努力（到目前为止）表明，据我所知，没有人认真倡导，因为普遍称为瀑布的高度僵化的软件过程[警告我可能没有遇到正确的参考]。不仅没有人倡导它，那些被称为瀑布的过程所归咎的人已经提倡出的东西，而不是目前的理解。最后，我会争辩说，如果您认为早期软件开发的环境发生在那些规划中心，文件繁忙的开发过程中有许多非常有效的原因被用作可用的最佳选择。
虽然最重要的是，我认为挑战一些共同的假设和＃39;普通知识＆＃39是很重要的;在技术世界中存在，并质疑该信息是否真实或以某些方式呈现服务个人或商业议程。我碰巧认为＆＃39;瀑布＆＃39;是这种事情的一个强大的例子，而且通过了解背景，您作为读者可能较少倾向于接受面值的语句，并做出更批判的思维。这就是为什么我使用的所有来源都是完全记录的，并且对于其中大多数，我可以在可能的情况下提供直接链接。它可以选择验证我的工作并形成自己的意见。
我还会说它＆＃39;很重要，了解出现不同想法和方法的背景。通过了解上下文，您可以了解可能在上下文更改中重新评估的内容，并在您自己的情况下识别类似的上下文。这样，您可能更好地了解您当前的上下文中可能工作的内容以及为什么，为什么拯救您必须学习艰难的方式。
你可能不关心这一切。或所涉及的历史。或者真的说的“来源”。您可能会发现所有上下文信息繁琐和不感兴趣。在这种情况下，随意阅读它是什么？紧接在下面，然后跳过起源部分并忽略两者之间的一切。
但如果您发现它有趣，请阅读整篇文章。如果您知道我没有触及的参考资料是合适的，请告诉我。我完全打开了改变这篇文章，但我想确保大多数文章都在实际参考。然后，人们可以根据证据形成自己的意见。
我的结论在阅读所有我到目前为止的情况下就像我开始完成所有这项研究之前一样。没有普遍适用的发展方法。您需要根据手头的情况定制您的开发过程。有时它会看起来非常“敏捷”，有时它会看起来非常“瀑布”，有时也有两个或两者都没有。正如一再说，没有银弹。
奇怪的是，这可能是瀑布最有争议的方面。似乎有一个普遍的“了解”是瀑布是技术世界中众多人中的伟大人群的普遍“理解”，但我认为“了解”的任何参考文献都不支持，这些参考资料被评为瀑布的“来源” 。
我可以根据我的阅读提出的最佳初始描述是瀑布模型是一个系统（或软件）开发生命周期（SDLC）过程模型，该过程是项目管理和解决方案设计的焦点;并利用高度规范的规格驱动的开发过程。它可能是SDLC模型的第一个正式化实例，并且几乎每个软件开发模型都包含了一些功能。 [32]
目前叫做瀑布的是经常被Winston W. Royce在1970年的文件中提出的，但概念过程的各个方面返回了赫伯特D.Benington的至少一个1956纸。 [1,32]
然而，瀑布模型也被一些在软件开发社区中的一些高度争议。事实上，有些人已经呼唤它是一个有毒的概念，[4]以及世界上最昂贵的错误。 [17]部分原因是人们如何定义瀑布模型的宽范围差异。而且我认为这部分是由于愿望将瀑布作为一个有用的稻草用于促进个人议程。这些是由于瀑布历史的常见误解，并且由于随着时间的推移所谓的瀑布的性质而变化。
通常，瀑布模型在当前时间描述的方式似乎高度依赖于描述它的人的知识，议程和个人偏见。
那么为什么它叫做瀑布模型？首先，您需要知道罗伊斯在描述他的工作中并理解瀑布模型名称被其他人分配的术语。
其次，它有助于看看模型的常见视觉表示，例如下面的模型（类似于Wikipedia上使用的模型）：
图A. 如果你看那个图表，那么“瀑布”的常见描述为......每个相级联到下一个级联，你知道，就像瀑布开始有意义的那样。 [10]
但是，对瀑布的最古老的参考不会以这种方式使用“瀑布”名称，并允许更多的细节解释。最早参考“瀑布”来自Bell＆amp的1976年的研究文件; Thayer，[12]罗伊斯发表论文后6年。下面包括完整报价，因为我认为它提供了罗伊斯论文最初被认为的良好例子，并且“瀑布”命名法不是最初的意思，这是稍后的方式被解释。
软件系统开发方法的演变通常平行于执行代码的思想的演变。在过去十年中，采用了更多的结构和纪律，从业人员得出结论，自上而下的方法优于过去的自下而上的方法。军事标准Set Milstd 490/483通过指定系统要求文件，A＆＃34;设计为＆＃34;要求响应系统要求创建的文件，然后是A＆＃34;代码为＆＃34;要求设计的每个软件模块的文件。这些中的每一个都比前者更低的细节，因此系统开发人员通过自上而下的过程来领导。在没有专门的军事行话的情况下，在罗伊斯的优秀纸上解释了同样的自上而下的方法，没有专门的军事行话[5];他介绍了发展活动瀑布的概念。在这种方法中，软件是在图1所示的学科的活动序列中开发的。[图1是如下图所示的标准瀑布图] 瀑布早期阶段中的每份文件都可以被视为陈述一系列要求。在每个级别，一组要求用作输入，并且设计为输出。然后，这种设计成为在下一个级别下为设计者设置的要求。有了这么多级别的要求文件，并且很少有软件项目很好地映射到该计划中，我们必须更具体地了解我们的意思术语和＃34;软件要求＆＃34;如我们研究所用。我们并不意味着所有各种各样的要求，但只有一个人，通常可以在已经成功结束的大型软件开发项目中识别。在此级别，软件要求描述了软件必须执行的功能，而不是如何实现它们。例如，它们可能包含一个要求BMD系统识别具有五种特定特征中的任何一个的错误雷达返回。但是，要满足此要求的软件可能会使用大量识别技术传播十二个子程序。 [12]（强调我的）
讨论瀑布模型的问题是，对其的是至少有两个显着不同的理解。最常见的解释是我在本文中称之为“冷冻瀑布”。另一个是最初在纸上描述的罗斯。因为罗伊斯最常见于瀑布法的“来源”，所以我将赋予他所描述的术语“瀑布”的优先事项。
因此，出于本文的目的，我将把瀑布视为罗伊斯在1970年纸上完全支持的过程。但首先，我认为我们需要解决“冷冻”[10]瀑布解释。
最常见的是使用如上面的图（例如在维基百科上的一个娱乐中的图表（这是一个在维基百科的娱乐）中，通常被描述为具有以下特征：
它是一个由若干阶段组成的顺序，刚性计划的过程，必须按顺序完成。 [25,33,34,38]
每个阶段是筒仓，完全与其他阶段分开，一旦相位完成，每相的结果都会被冷冻。 [10,38]
在项目团队搬迁到下一阶段之前，每阶段必须在100％确定。 [5,10,33,34]
它忽略了最终用户的开发和最终用户参与要求规范。 [4]或者如果在编码后提出要求更改，则在不涉及利益相关者的情况下进行。 [24]
一旦要求阶段完成[5,10,34,36,37]，它可能永远不会改变要求，因此它假设人类开发人员能够在第一次尝试时正确地获得要求，设计和测试。 [4,36]（强调我的）
它将分析从设计分析，强制开发人员生成解决方案，而不为如何生成解决方案提供任何指导。 [4]
这有很多引用了这一“冻结”瀑布方法，特别是来自'敏捷'的支持者，但我找不到一篇论文，这些纸张截止了这一版本的瀑布方法。我可以找到相当多的谁将这些特征归因于“瀑布”，而通常会引用罗伊斯论文，但没有这实际上支持这一点（包括罗伊斯）。从我可以说的话，这个“冰冻的瀑布从未被任何人倡导过，虽然可能存在由于那些试图遵循他们认为的”瀑布“过程的人的无知所存在。
Qinetiq是英国政府机构的一部分的英国国防承包商的白皮书中，可以在白皮书中找到更少的自以为是的，更多的学术描述。 [25] Qinetiq论文指出瀑布模型是基于许多假设：
但即使在阅读为瀑布基础的各种文件读取各种文件时，也似乎很大程度上是不支持的。
因此，如果上述描述是为了“冷冻”瀑布的解释，罗伊斯提出的瀑布模型究竟是什么是由他人修改的瀑布模型作为“该做什么”的想法，而不是“不做什么”？
根据我对文献的阅读（主要是下面），我会说，一般来说，“瀑布”模型具有以下特点：
它是一种过程，通过规划，文档和过程控制来旨在降低风险和成本。
它包括在开发开始之前引出，分析，评估和确认用户和业务需求的重要前台努力，以减少稍后需要进行的重新编码量，并确保（尽可能多地） ）系统架构足以满足客户端的当前和未来需求。
它是一个重点关注的过程，不仅仅是在开发的软件上，而是强烈的因素在上下文中，软件将用于软件产品的完整生命周期（开发，测试，部署，维护，增强和退休） 。
该过程包括在自然界中大致顺序的一组相，在后期阶段取决于先前阶段的输入。但是，这些阶段可以重叠，交互和重新审视。
由于其规划性的性质，整个周期通常完成少数次（最常见的1到2次）。如果执行不止一次，则第一周期通常用于创建原型。
该过程通常用于大规模，复杂的努力，需要在多个团队之间进行仔细协调，以便成功。
一旦达到了整个过程中的某个阶段（通常要求签名），正式的变更控制过程用于管理变更努力。
通过将每个阶段分为两个部分来集成质量保证：第一部分执行相位的工作，第二部分验证它。 [32]
请注意，以上描述并不意味着在下一阶段可以接合之前必须100％完成。这意味着，通常，如果您想进行分析，您需要有一些要分析的东西。因此，软件要求活动的结果（可以有多个活动）将是分析活动的输入，这反过来是输入设计活动的输入。
在讨论瀑布模型的历史和细节之前，我认为读者首先了解它开发的背景至关重要。
1950年代和1960年代是计算机时代的前2年。这主要是大型机计算机的时代，迷你计算机开始于1960年年中出现在现场。个人计算机，如IBM PC和Macintosh在这段时间内甚至不是考虑因素，因为它们直到1980年代早期到20世纪80年代。
此外，即使是最好的计算机的能力也比现代计算机更长。许多软件正在被开发为集成系统的一部分，其中计算速度，内存量和系统设计的问题都影响了软件如何运行，并且资源稀缺构成了现代程序员很少要处理的资源稀缺的挑战。 [1]
大多数发展可能是在大会，algol（1950年代中期），Fortran（1957年的第一个编译器），Comtran（1957年发布的第一个编译器），COBOL（在1962年更换了IBM的COMTRAN） ）和PL / I（第一编译器1966）。
在1970年代早期，没有开发C编程语言，而不是在1970年代后期正式形成。直到1980年中期，大多数面向对象的语言都没有得到广泛的应用。
使用的语言不太简洁，因此更多地受到编码错误。例如，像C的现代语言的简单Hello World程序可以在4行或更少的时间内完成。在像COBOL这样的旧语言中，它需要17行代码。 [20]
最后，软件开发工具更简单。虽然更好的开发工具在20世纪60年代中期中期的现代工具中变得更加常见，但像代码突出显示，强大的综合开发环境（IDE），像Git这样的版本控制系统，以及许多制造现代发展的其他工具更高，质量更高当时不存在。
虽然1950年代的早期软件开发商大多是工程师或数学家，但到了1950年代后期和1960年代早期，方案师的需求大大超过了工程和数学背景的人数。编程领域与人文，社会科学，外语和美术中的培训的人淹没。 [21]据报道，其中许多人受到1960年代的问题权威态度的影响，并抵抗了组织和管理发展过程的抵抗力。
这些问题中的许多问题持续良好进入1970年，在1975年的调查发现14个大型组织的普通编码器有两年的大学教育和两年的软件体验;熟悉两个编程语言和软件产品;并且通常是邋，inflexible，＆＃39;在他的头上＆＃39;，和托管。 [21]当然，该陈述是多少代表现实以及它代表偏差的程度是不可能告诉40年后的偏见。但它给出了时间问题的视角。
由于当时的开发环境和开发人员的类型，因此编程的代码和修复风格是毫不奇观的，这是1960年代中最常见的过程。开发人员往往非常有创意，但编码过程，然后修复错误，然后编码更多，然后修复更多的错误，往往会导致大量修补的意大利面条代码。 [21]
结构化编程的概念，如使用子例程，块结构和循环[22]只开始在1960年代后期变得普遍，即使那么许多程序员之间的抵抗力要努力使代码更可读，容易维护和修复。
现代发展与1950年代，1960年代，1970年代的危重差异在成本中心。 在目前的环境中，计算资源如此便宜和丰富，以至于开发人员，项目人员和相关个人远远超过了所消耗的任何计算资源的成本。 但是，情况一度恰恰相反。 随着Barry Boehm涉及的是，在我的第一天在工作[1950年代]，我的主管向我展示了一个1103台电脑，填补了一个大房间。 他说，＆＃39;现在 ......