前言

你一定知道瀑布开发模型，也一定知道瀑布开发模型在当代敏捷盛行的背景下被广为诟病甚至被抛弃，几秒钟内你就能想到几点瀑布开发方法的缺点。但事实上瀑布真的是我们想象中的那么不堪吗？今天这篇文章我们将尝试对Winston W. Royce博士在 1970 年发表的《管理大型软件系统的开发》论文提出的"瀑布开发"（事实上Winston W. Royce并未给这种开发方法进行命名）进行解读，对瀑布进行逐本溯源，加深我们对瀑布模型发展的理解。

论文原文和译文如下（翻译存在不准确，请读者指正）。

---

《管理大型软件系统的开发》

Dr. Winston W. Royce-1970

引言

我将介绍我个人关于管理大型软件开发的观点。在过去的九年里，我曾担任各种任务，主要涉及航天器任务规划、指挥和飞行后分析软件包的开发。在这些任务中，我经历了不同程度的成功，包括按时完成、控制成本，以及达到可运营状态。我的经验使我对于大型软件开发管理产生了一些观点，我将在这篇文章中分享其中一些。

INTRODUCTION

I am going to describe my personal views about managing large software developments. I have had various assignments during the past nine years, mostly concerned with the development of software packages for spacecraft mission planning, commanding and post-flight analysis. ln these assiqnments i have experienced different degrees of success with respect to arriving at an operational state, on-time, and within costs. I have become prejudiced by my experiences and I am going to relate some of these prejudices in this presentation.

计算机程序功能开发

无论大小或复杂程度如何，所有计算机程序开发都有两个基本步骤。首先是分析步骤，然后是编码步骤，如图1所示。这种非常简单的实施概念实际上只在工作量足够小且最终产品将由开发它的人操作时需要。这通常是内部使用的计算机程序所采用的开发方式，这也是大多数客户愿意支付报酬的开发工作，因为这两个步骤都涉及到真正的创造性工作，直接有助于最终产品的可用。然而，如果开发更大型软件系统只针对这些步骤制定计划，那注定会失败。还需要许多额外的开发步骤，这些开发步骤不像分析和编码步骤一样直接为最终产品产生价值，而且所有这些步骤都会增加开发成本。通常客户人员不愿意为它们付费，而且开发人员也不愿意实施它们，管理者的主要职能是向这两个群体推广这些概念，然后强制开发人员遵守。

COMPUTER PROGRAM DEVELOPMENT FUNCTIONS

There are two essential steps common to all computer program developments, regardless of size or complexity. There is first an analysis step, followed second by a coding step as depicted in Figure 1. This sort of very simple implementation concept is in fact all that is required if the effort is sufficiently small and if the final product is to be operated by those who built it – as is typically done with computer programs for internal use. It is also the kind of development effort for which most customers are happy to pay, since both steps involve genuinely creative work which directly contributes to the usefulness of the final product. An implementation plan to manufacture larger software systems, and keyed only to these steps. however, is doomed to failure. Many additional development steps are required, none contribute as directly to the final product as analysis and coding, and all drive up the development costs, Customer personnel typically would rather not pay for them, and development personnel would rather not implement them, The prime function of management is to sell these concepts to both groups and then enforce compliance on the part of development personnel.

软件开发的更宏伟方法如图2所示。分析和编码步骤仍然存在，但它们之前有两个级别的需求分析，它们之间由一个程序设计步骤分隔，并且之后有一个测试步骤。这些附加步骤与分析和编码分开处理，因为它们在执行方式上有明显的不同。它们必须以不同的方式进行计划和配置资源，以最大限度地利用程序资源。

A more grandiose approach to software development is illustrated in Figure 2, The analysis and coding steps are still in the picture, but they are preceded by two levels of requirements analysis, are separated by aprogram desin step, and followed by a testing step. These additions are treated separately from analysis and coding because they are distinctly different in the way they are executed. They must be planned and staffed differently for best utilization of programn resources.

图3展示了这个方案中连续开发阶段之间的迭代关系。步骤的顺序基于以下概念：随着每个步骤的推进和设计的进一步详细，与前后步骤之间存在迭代，但与序列中更远的步骤的迭代很少发生。这一切的优点在于，随着设计的进行，变更过程被限定在可管理的范围内。在需求分析完成后的设计过程的任何时刻，都存在一个坚实而密切的、不断前进的基线，以备在出现意外的设计困难时返回。我们拥有的是一个有效的备用位置，倾向于最大程度地保留和保存早期工作的范围。

Figure 3 portrays the iterative relationship between successive development phases for this scheme. The ordering of steps is based on the following concept: that as each step progresses and the design is further detailed, there is an iteration with the preceding and succeeding steps but rarely with the more remote steps in the sequence. The virtue of all of this is that as the design proceeds, the change process is scoped down to manageable limits. At any point in the design process after the requirements analysis is completed, there exists a firm and closeup, moving baseline to which to return in the event of unforeseen design difficulties. What we have is an effective fallback position that tends to maximize the extent of early work that is salvageable and preserved.

我相信这个概念，但上述描述的实施方式存在风险，并容易导致失败。问题如图4所示。开发周期结束时的测试阶段是第一个开始验证时序、存储、输入/输出传输等而非依然进行分析的阶段。这些现象无法精确地分析，例如：它们不是数学物理学标准偏微分方程的解。然而，如果这些现象不能满足各种外部约束条件，那么通常需要进行重大重新设计。简单的八进制修补或对某些孤立代码的重做无法解决这些问题。所需的设计更改可能会破坏到设计基础并提供了一切合理性的软件需求。要么修改需求，要么需要对设计进行重大更改，实际上，开发过程已经回到原点，可以预期进度和/或成本会超出100%。

I believe in this concept, but the implementation described above is risky and invites failure. The problem is illustrated in Figure 4. The testing phase, which occurs at the end of the development cycle, is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics, for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provide the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect, the development process has returned to the origin, and one can expect up to a 100-percent overrun in schedule and/or costs.

可以注意到分析和编码阶段被跳过了。当然，没有这些步骤就不能产生软件，但通常这些阶段管理相对容易，并且对需求、设计和测试影响不大。根据我的经验，有些部门致力于轨道力学分析、航天器姿态确定、负载活动的数学优化等分析工作。但当这些部门完成了困难和复杂的工作后，所产生的程序步骤只涉及几行串行算术代码。如果在执行困难和复杂的工作时分析师犯了错误，那么通常通过对代码进行微小的更改来进行修复，而不会对其他开发基础产生破坏性的影响。

然而，我认为上述所示的方法基本上是可行的。本讨论的其余部分提出了必须添加到这个基本方法中的五个附加特征，以消除大部分开发风险。

One might note that there has been a skipping over of the analysis and code phases. One cannot, of course, produce software without these steps, but generally these phases are managed with relative ease and have little impact on requirements, design, and testing. In my experience, there are whole departments consumed with the analysis of orbit mechanics, spacecraft attitude determination, mathematical optimization of payload activity, and so forth. But when these departments have completed their difficult and complex work, the resultant program steps involve a few lines of serial arithmetic code. If in the execution of their difficult and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.

However, I believe the illustrated approach to be fundamentally sound. The remainder of this discussion presents five additional features that must be added to this basic approach to eliminate most of the development risks.

步骤1：进行程序预设计

第一步如图5所示。在软件需求生成阶段和分析阶段之间插入了初步的程序设计阶段。这个阶段可能会遭到批评，因为程序设计师被迫在没有任何现有分析和初始软件需求相对匮乏的情况下进行程序设计。因此，他的初步设计可能与分析完成后再设计相比会存在实质性的错误。这种批评是正确的，但它忽略了关键点。通过这种技术，程序设计师确保软件不会因存储、时序和数据流问题而失败。随着分析在后续阶段的进行，程序设计师必须以一种方式同步给分析师存储、时序和操作约束，以便他能感知到这种约束。当他有正当理由需要更多这种资源来实现他的方程时，必须同时从他的分析师同事那里获取这些资源。通过这种方式，所有的分析师和程序设计师都将为一个有意义的设计过程做出贡献，最终将实现执行时序和存储资源的适当分配。如果要应用的总资源不足，或者如果初步的操作设计是错误的，那么在这个较早的阶段就会被识别出来，需求和初步设计的迭代可以在最终设计、编码和测试开始之前重新进行。

这个过程如何实施？需要以下步骤：

1. 由程序设计师开始设计流程，而不是分析师或程序员。
2. 设计、定义和分配数据处理模式，即使有可能出错也要分配处理功能，设计数据库，定义数据库处理，分配执行时序，定义与操作系统的接口和处理模式，描述输入和输出处理，并定义初步操作程序。
3. 编写一个可理解、信息丰富且当前的概述文档。每个工作者都必须对系统有基本的了解。至少有一个人必须对系统有深入的了解，这部分来自于必须编写概述文档。

STEP 1: PROGRAM DESIGN COMES FIRST

The first step towards a fix is illustrated in Figure 5. A preliminary program design phase has been inserted between the software requirements generation phase and the analysis phase. This procedure can be criticized on the basis that the program designer is forced to design in the relative vacuum of initial software requirements without any existing analysis. As a result, his preliminary design may be substantially in error as compared to his design if he were to wait until the analysis was complete. This criticism is correct but it misses the point. By this technique, the program designer assures that the software will not fail because of storage, timing, and data flux reasons. As the analysis proceeds in the succeeding phase, the program designer must impose on the analyst the storage, timing, and operational constraints in such a way that he senses the consequences. When he justifiably requires more of this kind of resource in order to implement his equations, it must be simultaneously snatched from his analyst compatriots. In this way, all the analysts and all the program designers will contribute to a meaningful design process which will culminate in the proper allocation of execution time and storage resources. If the total resources to be applied are insufficient or if the embryo operational design is wrong, it will be recognized at this earlier stage, and the iteration with requirements and preliminary design can be redone before final design, coding, and test commence.

How is this procedure implemented? The following steps are required:

1. Begin the design process with program designers, not analysts or programmers.
2. Design, define, and allocate the data processing modes, even at the risk of being wrong. Allocate processing functions, design the database, define database processing, allocate execution time, define interfaces and processing modes with the operating system, describe input and output processing, and define preliminary operating procedures.
3. Write an overview document that is understandable, informative, and current. Each and every worker must have an elemental understanding of the system. At least one person must have a deep understanding of the system, which comes partially from having had to write an overview document.

步骤2：设计文档化

在这一点上，提出“需要多少文档？”是恰当的。我的看法是“相当多”，肯定比大多数程序员、分析员或程序设计师愿意自行完成的要多。管理软件开发的第一条规则是严格执行文档要求。偶尔，我被要求审查其他软件设计工作的进展。我的第一步是调查文档的状态。如果文档存在严重问题，我的第一个建议很简单：替换项目管理者，停止与文档无关的所有活动。将文档提升到可接受的标准。没有高度文档化，软件管理就是不可能的。举个例子，让我提供以下估算供参考：为了采购一台价值500万美元的硬件设备，我期望一个30页的、提供足够的细节的规格说明书来控制采购。为了采购价值500万美元的软件，我估计需要1000页的规格说明书，以达到类似的控制水平。

为什么需要这么多文档？

1. 每个设计师都必须与接口设计师、管理层以及可能的客户进行沟通。口头记录过于抽象，不能为接口或管理决策提供足够的依据。一份可接受的书面描述迫使设计师采取明确的立场，并提供切实的完成证据。它阻止设计师在数月之后继续掩藏在“我已经完成了90%”的症候群背后。

2. 在软件开发的早期阶段，文档就是规格说明，也是设计。在编码开始之前，这三个名词（文档、规格说明、设计）表示同一件事。如果文档不好，设计也不好。如果文档还不存在，那么设计也还不存在，只有人们在思考和讨论设计，这对一定有一定的价值，但不多。

3. 良好文档的真正货币价值在开发过程中的后续阶段开始，在测试阶段继续，并持续到运维和重设计阶段。文档的价值可以通过以下三种具体而切实的情况来描述，这是每个项目经理都会面临的情况：

   a) 在测试阶段，有了良好的文档，管理者可以调度成员集中精力修复程序中的错误。没有良好的文档，每个错误，无论大小，都可能由制造这个错误的人来分析，因为他是唯一了解该程序编码的人。

   b) 在运营阶段，有了良好的文档，管理者可以使用以运营为导向的人员来操作程序，从而更好、更便宜地完成工作。没有良好的文档，软件必须由构建它的人员来操作。但是通常这些人对运营并不感兴趣，不如运营为导向的人员做得更好。需要指出的是，在运营环境出现问题，通常首先会怀疑软件问题，为了澄清问题和免除责任，软件文档必须清晰明了。

   c) 在开始运维需要进行系统改进时，良好的文档可以在现场进行有效的重设计、更新和改装。如果没有文档，通常必须废弃整个现有的操作软件框架，即使只进行相对较小的更改。

图6显示了一个与之前显示的步骤相关的文档计划。请注意，一共生成了六份文档，并且在交付最终产品时，文档1、文档3、文档4、文档5和文档6都是更新的且为最新状态。

STEP 2: DOCUMENT THE DESIGN

At this point, it is appropriate to raise the issue of - “how much documentation?” My own view is “quite a lot;” certainly more than most programmers, analysts, or program designers are willing to do if left to their own devices. The first rule of managing software development is ruthless enforcement of documentation requirements. Occasionally, I am called upon to review the progress of other software design efforts. My first step is to investigate the state of the documentation. If the documentation is in serious default, my first recommendation is simple: Replace project management. Stop all activities not related to documentation. Bring the documentation up to acceptable standards. Management of software is simply impossible without a very high degree of documentation. As an example, let me offer the following estimates for comparison: In order to procure a 5 million dollar hardware device, I would expect that a 30-page specification would provide adequate detail to control the procurement. In order to procure 5 million dollars of software, I would estimate 1,100-page specification is about right in order to achieve comparable control.

Why so much documentation?

1. Each designer must communicate with interfacing designers, with his management, and possibly with the customer. A verbal record is too intangible to provide an adequate basis for an interface or management decision. An acceptable written description forces the designer to take an unequivocal position and provide tangible evidence of completion. It prevents the designer from hiding behind the “I am 90 percent finished” syndrome month after month.

2. During the early phase of software development, the documentation is the specification and is the design. Until coding begins, these three nouns (documentation, specification, design) denote a single thing. If the documentation is bad, the design is bad. If the documentation does not yet exist, there is as yet no design, only people thinking and talking about the design, which is of some value, but not much.

3. The real monetary value of good documentation begins downstream in the development process, during the testing phase, and continues through operations and redesign. The value of documentation can be described in terms of three concrete, tangible situations that every program manager faces:

   a) During the testing phase, with good documentation, the manager can concentrate personnel on the mistakes in the program. Without good documentation, every mistake, large or small, is analyzed by one man who probably made the mistake in the first place because he is the only man who understands the program area.

   b) During the operational phase, with good documentation, the manager can use operation-oriented personnel to operate the program and to do a better job, cheaper. Without good documentation, the software must be operated by those who built it. Generally, these people are relatively disinterested in operations and do not do as effective a job as operations-oriented personnel. It should be pointed out in this connection that in an operational situation, if there is some hang-up, the software is always blamed first, in order either to absolve the software or to fix the blame; the software documentation must speak clearly.

   c) Following initial operations, when system improvements are in order, good documentation permits effective redesign, updating, and retrofitting in the field. If documentation does not exist, generally the entire existing framework of operating software must be junked, even for relatively modest changes.

Figure 6 shows a documentation plan that is keyed to the steps previously shown. Note that six documents are produced and at the time of delivery of the final product, Documents No. 1, No. 3, No. 4, No. 5, and No. 6 are updated and current.

步骤3：做两次

在文档编制之后，成功的第二个最重要的标准是产品是否从头开始开发。如果涉及的计算机程序是首次开发，那么请“做两次”，以便最终交付给客户用于运行部署的版本在关键的设计/操作领域实际上是第二个版本。图7通过模拟展示了如何通过这种方式来实现。请注意，这只是整个过程的缩影，相对于整体工作而言时间周期相对较小。这一工作的时间周期可以根据总体时间尺度和要建模的关键问题领域的差别而有很大差异。如果工作需要30个月，那么这个早期的试点模型的开发可能计划为10个月。对于这种时间表，可以使用相当正式的控制、文档程序等。然而，如果整体工作缩短到12个月，那么试点工作可能被压缩到三个月，以便在主线开发中获得足够的杠杆。在这种情况下，参与人员需要一种非常特殊的广泛能力。他们必须对分析、编码和程序设计有直观的感觉。他们必须迅速察觉设计中的问题点，对其进行建模，建立其替代方案，忽略在这个早期阶段设计中不值得研究的一些方面，最终得出一个无错误的程序。无论哪种情况，所有这些工作的目的，就像模拟一样，是以精确的方式研究否则是判断问题的时序、存储等问题。没有这个模拟，项目经理将受制于人的判断。有了这个模拟，至少可以执行一些关键假设的实验性测试，并将仍然需要人的判断的范围缩小，而在计算机程序设计领域（就像估算起飞总重、完成成本等），人的判断总是极其乐观的。

STEP 3: DO IT TWICE

After documentation, the second most important criterion for success revolves around whether the product is totally original. If the computer program in question is being developed for the first time, arrange matters so that the version finally delivered to the customer for operational deployment is actually the second version insofar as critical design/operations areas are concerned. Figure 7 illustrates how this might be carried out by means of a simulation. Note that it is simply the entire process done in miniature, to a time scale that is relatively small with respect to the overall effort. The nature of this effort can vary widely depending primarily on the overall time scale and the nature of the critical problem areas to be modeled. If the effort runs 30 months, then this early development of a pilot model might be scheduled for 10 months. For this schedule, fairly formal controls, documentation procedures, etc., can be utilized. If, however, the overall effort were reduced to 12 months, then the pilot effort could be compressed to three months perhaps, in order to gain sufficient leverage on the mainline development. In this case, a very special kind of broad competence is required on the part of the personnel involved. They must have an intuitive feel for analysis, coding, and program design. They must quickly sense the trouble spots in the design, model them, model their alternatives, forget the straightforward aspects of the design which aren’t worth studying at this early point, and finally arrive at an error-free program. In either case, the point of all this, as with a simulation, is that questions of timing, storage, etc., which are otherwise matters of judgment, can now be studied with precision. Without this simulation, the project manager is at the mercy of human judgment. With the simulation, he can at least perform experimental tests of some key hypotheses and scope down what remains for human judgment, which in the area of computer program design (as in the estimation of takeoff gross weight, costs to complete, or the daily double) is invariably and seriously optimistic.

步骤4：计划、控制和监督测试

毫无疑问，项目中无论是人力、计算时间还是管理判断资源消耗最多的都是测试阶段。从成本和进度的角度来看，这是风险最高的阶段。它发生在进度表的最后阶段，此时备用方案可能不可用，如果有的话。

前面的三个建议，即在开始分析和编码之前设计程序、良好的文档记录以及构建试验模型，都旨在在进入测试阶段之前识别和解决问题。然而，即使在采取了这些措施之后，测试阶段仍然存在，并且仍然有关键的任务要执行。图8概述了测试的一些附加方面。

在测试计划中，我建议考虑以下几点：

1. 测试过程的许多方面最好由测试专家处理，这些专家可能没有参与最初的设计。如果有人主张只有设计者才能进行彻底的测试，因为只有他们能理解他们构建的领域，这很可能表明文档记录不足。通过良好的文档记录，可以聘请软件产品保证方面的专家，我认为他们能够比设计者更有效地进行测试。
2. 大多数错误都是明显的，可以通过目视检查轻松发现。每一部分分析和每一部分代码都应该由没有参与原始分析或编码的第三方进行简单的目视检查，以发现问题，比如遗漏的负号、遗漏的乘以二的因子、跳转到错误地址等。这类似于对分析和代码进行校对。避免使用计算机来检测这些类型的错误，因为这可能代价高昂。
3. 至少用某种形式的数值验证测试计算机程序中的每一逻辑路径一次。如果我是客户，我不会在此程序完成和获得认证之前接受交付。这一步将揭示大多数编码错误。尽管这种测试程序听起来很简单，但对于大型复杂的计算机程序，使用受控输入值详细检查每个逻辑路径可能会很具挑战性。有些人甚至可能会认为这几乎是不可能的。尽管如此，我仍然强烈建议对每个逻辑路径进行至少一次彻底的验证。
4. 在消除简单错误（它们构成大多数，通常掩盖了重大错误）之后，是时候将软件交给测试团队进行全面验证了。在开发过程中的适当时机，并在合适的人员监督下，计算机本身是进行验证的最有效工具。关键的管理决策包括确定适当的时间和适当的人员来进行最终验证。

STEP 4: PLAN, CONTROL, AND MONITOR TESTING

Without question, the most significant consumer of project resources, be it manpower, computer time, or management judgment, is the testing phase. It represents the phase with the highest risk in terms of costs and schedule. It occurs at the latest stage in the schedule when backup alternatives are least available, if available at all.

The previous three recommendations to design the program before starting analysis and coding, to fully document it, and to construct a pilot model all aim to identify and resolve issues before entering the testing phase. Nevertheless, even after implementing these measures, a testing phase remains, and there are still critical tasks to perform. Figure 8 outlines some additional aspects of testing.

In planning for testing, I would suggest the following considerations:

1. Many aspects of the testing process are best handled by testing specialists who may not have been involved in the initial design. If it is argued that only the designer can conduct a thorough test because they alone understand the area they built, this likely indicates a failure to document adequately. With proper documentation, it is feasible to employ specialists in software product assurance who, in my opinion, can perform testing more effectively than the designer.
2. Most errors are of an obvious nature and can be easily detected through visual inspection. Every piece of analysis and every section of code should undergo a simple visual review by a third party who was not involved in the original analysis or coding but can identify issues like missing minus signs, missing factors of two, jumps to incorrect addresses, etc. This is akin to proofreading the analysis and code. Avoid using the computer to detect these types of errors as it can be costly.
3. Test every logical pathway in the computer program at least once with some form of numerical validation. If I were a customer, I would not accept delivery until this procedure was completed and certified. This step will uncover the majority of coding errors. While this testing procedure may sound simple, for a large, complex computer program, thoroughly checking every logical pathway with controlled input values can be challenging. Some may even argue it’s nearly impossible. Nevertheless, I would strongly recommend subjecting every logical pathway to at least one rigorous validation.
4. After eliminating the simple errors (which constitute the majority and often obscure major mistakes), it’s time to hand over the software to the testing team for comprehensive verification. At the appropriate point during the development process and under the supervision of the right individual, the computer itself is the most effective tool for verification. Key management decisions include determining when the right time is and who the right person is to conduct the final verification.

步骤5：让客户参与

出于某种原因，即使在先前达成协议之后，软件设计的确切功能也可能存在不同的理解。因此，有必要以正式的方式让客户参与，以确保在最终交付之前他们在早期阶段已经做出了承诺。在需求定义和操作之间让承包商自由发挥会引入大量问题。图9突出显示了在需求定义之后的三个关键点，客户的洞察力、判断力和承诺可以增强开发工作。

STEP 5: INVOLVE THE CUSTOMER

For some reason, the exact functionality of a software design can be subject to wide interpretation even after previous agreement. It is crucial to formally involve the customer to ensure their commitment at earlier stages before final delivery. Allowing the contractor unrestricted control between defining requirements and operation is an invitation to problems. Figure 9 highlights three points following the definition of requirements where the insight, judgment, and commitment of the customer can enhance the development effort.

总结

图10总结了我认为将高风险的开发过程转变为能够提供所需产品的五个步骤。我要强调的是，每个步骤都伴随着一定的成本。如果一个不涉及这里描述的五个步骤且相对简单的过程能够保障大型软件开发成功，那么额外的开支可能就不值得。然而，根据我的经验，在大型软件开发项目中，较简单的方法从未取得成功，而从失败中恢复所需的成本远远超过了实施所列五个步骤的成本。

SUMMARY

Figure 10 provides a summary of the five steps that I believe are necessary to transform a risky development process into one that will deliver the desired product. I want to emphasize that each of these steps comes with an associated cost. If a relatively simpler process, without the five complexities described here, were to work successfully, then, of course, the additional expenditure may not be justified. However, in my experience, the simpler method has never proven effective in large software development endeavors, and the expenses required to recover from failures far exceed the costs of implementing the five-step process outlined.

---

对瀑布的误解

误解1 Royce定义并推荐瀑布模型

Royce并没有在论文中定义瀑布模型并推荐使用，论文中他指出了瀑布模型的主要问题之一：在测试阶段发现问题可能是破坏性的，并有可能导致系统的需求、设计进行重大调整，开发过程会被打回到原点，进度和成本将超过100%。指出问题的同时并提出了修正建议。

误解2 瀑布没有敏捷思想

这里并不能说明瀑布是具有敏捷性的，但从论文中Royce针对识别到的瀑布模型的问题给出了对应的增强功能（解决问题的5个步骤）：

1. 对程序进行预先设计
2. 设计文档化
3. 做两次
4. 计划、控制和监督测试
5. 让客户参与

预设计与高度的文档化是以现在的视角来看是不灵活的，但Royce文章主要讨论的焦点主要是围绕《管理大型软件系统开发》，我个人觉得在这样的主题和背景下还是有一定的合理性。接下来我们重点看后面的3点：

做两次

做两次的方法已经有了原型的概念，本意上是通过前期对软件小尺度的建模和开发来尽早发现问题，以确保整个系统的成功。

计划、控制和监控测试

Royce指出测试放到最后会导致糟糕的后果，但他也并未草率的得出测试应该放到第一位的结论，而是非常强调测试对软件项目成功的重要性。他还表示，代码应该由第三方进行检查、尽可能的覆盖路径、做全面的测试等，这让我想到后来发展起来的V模型、左移和代码覆盖率的一些概念和方法。

让客户参与

有些人解读瀑布是尽可能少的让客户参与开发，因为需求就是客户与开发团队之间的契约和合同。但事实上Royce强调应该让客户参与到软件研发中来，而且参与应该是正式的、深入的、持续的。读到这里是不是已经有了一点敏捷的味道？

Royce在文中提到“在承包商在需求定义阶段到运营阶段之间自由发挥会带来麻烦”，所以他给出了建议，在关键节点客户要参与到软件研发中来。

那么Winston W. Royce敏捷吗？当然不是，但他对如何改进软件开发有了一些非常好的想法，其中有一些已经比较“敏捷”。但事实上我们大多数人以前从未听说过这些。

缺陷如此明显，为何如此流行？

从国外的一个博客上看到了这样的一个无从考证的谣言。当时美国国防部的某个人被安排了寻找新的软件开发方法来开发新系统的任务。他看到了Winston W. Royce的论文并阅读了第一页并看到使用图形描述的我们所熟知的“瀑布”模型。由于它简单并看起来不错，继续对流程进行了补充，但实际他并没有阅读流程缺陷和建议的增强功能部分。

不管谣言与否，我觉得Winston W. Royce从最开始就被误解了。虽然经历几十年瀑布开发模型已经不占主导，但追根溯源去了解最原始的瀑布也是有益的，有助于我们深入了解软件开发方法的演进，理解软件开发模型的本源。