PDF“瀑布模型的末日即将来临” 以及其他都市传说
Phillip A. Laplante 和 Colin J. Neill，宾夕法尼亚州立大学
关于瀑布生命周期模型末日的谣言被大大夸大了。我们在最近一项针对近200名软件专业人士的调查中发现了这一现象以及其他令人失望的关于当前软件工程实践的指标。这些发现引发了关于软件工程师的本质、软件工程实践以及行业方面，认知与现实之间差异的疑问。
为什么都市传说会在软件工程中存在？
大约两年前，我们问自己一个问题：“在软件系统的规范和设计中，真正使用了哪些实践？” 我们通常认为瀑布模型的使用已经过时，并且各种最佳实践已被采用。我们的理解是基于作者们反复强调的假设，但我们记不清这些立场的理由。不幸的是，对文献的检索并没有为传统观点提供令人信服的支持。鉴于缺乏数据，因此，我们认为对来自国防、制药、化工、电信、银行和政府行业（包括几家财富500强公司）各种规模公司的从业者进行调查将是有启发意义的。
我们构建了一个基于Web的调查工具，但与其列举问题或调查机制，我们不如引导读者访问该网站。1 数据收集在2002年春季的七周内完成。在收到电子邮件邀请和提醒的1,519人中，有194人完成了调查2，回复率约为13%。
调查结果使我们确信，所谓的传统观点类似于都市神话。这些神话之所以存在，是因为我们想相信它们——并且因为没有数据可以反驳它们。
别担心。我们不打算在这里回顾调查结果。这些结果可以在我们之前发表的一篇文章中找到，没有解释。3 相反，我们想对一些更有趣的回复及其含义发表看法。但是请注意，我们即将进入“无旋转区”，或者更恰当地说，“无神话区”。
神话 1：瀑布生命周期模型的末日即将来临
瀑布过程模型（其中软件产品被视为从概念、需求、设计、代码和测试线性发展的过程）是昔日的遗物。由温斯顿·罗伊斯4 在1970年计算机系统是单片式的、数字运算实体，具有简陋的前端（以今天的标准衡量），用户的需求通过构建系统的计算机精英的偏见思维过滤时引入（但未命名）。
好吧，也许这有点过分，但公平地说，那个时代构建的大多数系统都是由程序员自己规范的——很少有我们现在所说的利益相关者的投入。在这样的环境中，瀑布模型是有效的。需求在规范制定后很少变化，因为用户不参与开发；他们无法提供关于不正确的假设或缺失的功能和需求的反馈。然而，这个时代已经结束了。软件系统与用户越来越接近，以至于他们的声音不能被忽视；如果系统不满足他们的需求，他们会拒绝该系统。
这引入了一个对需求变更的重大推动力，而线性顺序模型（为了保护罪魁祸首而狡猾地改名）无法容忍这种变更。这种开发模型假设需求在分析开始之前是确定的、稳定的和完全演变的，因为开发从需求阶段到系统部署阶段线性地进行。只有当在该阶段创建的工件未通过检查、审查或测试时，才会重新访问某个阶段。如果你遇到有人反驳这种说法，提醒他们水不会逆流而上。
软件开发的现代现实是，变更是不可避免的，因此必须在生命周期中明确地适应变更。这不是必须修复的错误；它是系统构建的自然方面。这种变更不仅限于需求，但需求示例是最直接和最重要的。我们对某件事了解得越多，我们就越意识到我们最初的假设和概念中的缺陷。如果我们不能轻易地使我们的解决方案适应这些变更，那么适应这些需求“错误”的成本将呈指数级增长。
为了适应这些问题，人们提出了许多替代过程模型。对标准瀑布模型的早期修改引入了原型设计作为反馈和发现机制，以便可以及早发现最初的误解和遗漏。随后的过程模型试图通过将项目分解为一系列“迷你瀑布”并迭代任务，或以一系列最终形成完整功能的版本交付整个系统的增量，从而进一步减轻此类风险。
令人惊讶和失望的是，在对近200名从业人员进行的调查中，考虑到过去五年中的数千个项目，报告中最主要的过程模型是瀑布模型，超过三分之一的人声称使用了它。5 这一结果提出了一个问题：从业的专业人士在看到瀑布模型时是否知道它是什么？也许他们将其与其他过程模型混淆了。这似乎不太可能，但它的主导地位也是如此。更有可能的是，在许多情况下，做错事比做对事更容易——而这不是成功的秘诀。
事实是，尽管取得了很大进展，但瀑布模型还没有完全消亡。很多人将其视为他们首选的开发方法。要么他们准确地描述了情况，这很糟糕，要么他们感到困惑，情况也好不到哪里去。无论哪种情况，瀑布模型的消亡都让我们难以捉摸，唉。
神话 2：我们丢弃我们的第一次尝试
与生命周期模型的选择密切相关的是原型设计问题。对于许多人来说，支持原型设计的论点就像支持母亲和苹果派的论点一样：为什么你不想用快速构建的模型或骨架来探索问题空间呢？每个参与者都可以尝试他们的想法并验证他们对当前问题的理解。它还为客户讨论和反馈提供了理想的机制。因此，我们都同意原型很棒。
嗯，实际上，这太简单化了。尽管很难反对原型设计本身，但很容易反对原型设计在实践中的应用。开发人员和其他人一样，讨厌丢弃他们的劳动成果。“我已经构建了一次，每个人都喜欢它，为什么我必须重新构建它？” 这是常见的抱怨。至少对我们来说，显而易见的回答是：“它是否像‘生产级代码’（无论那意味着什么）一样健壮、可维护、可靠，因此经过了充分的测试？”
在其他工程学科中，这不是问题，因为原型不能用于最终系统；它们是制造出来的。在软件中，制造过程是磁盘复制，这使得原型可以用作最终生产系统。
我们看不到这有什么优势。软件行业一直未能交付健壮、可靠、无错误的系统，但我们仍然允许解决方案中存在未经受生产开发严格考验的元素；在原型中，通常会推迟结构和架构方面的考虑，并且很少考虑诸如异常处理之类的基本实践。
这里应该应用一句恰当的短语：“扔掉第一个”。这个建议并不新鲜；弗雷德·布鲁克斯在《人月神话》6 中写到了它。不幸的是，20年后，这仍然不是主流做法。我们的调查询问了受访者是否执行原型设计，如果他们这样做了，他们是允许这些原型演变成生产系统（演进式原型设计）还是丢弃它们。该调查问题的结果表明，有一半的时间使用了演进式原型设计。我们认为，只要稍加思考，许多人可能会觉得这不言而喻——问问你自己，你或你的团队中的任何人是否保留原型？该代码（以原始形式或演进形式）是否进入最终设计？不仅我们的调查，而且经验也表明了令人失望的现实。
现在，我们并不是说演进式原型设计不能成功使用。例如，无情的重构（设计修复）可以提高现有代码的质量。此外，需求很少的情况会从这种方法中获益匪浅。
我们担心的是，演进式原型设计被用于并非为其构想的情况，而仅仅是对于糟糕的开发实践的正式名称，在这些实践中，最初的开发尝试被保留而不是丢弃和重新开始。代码可能会编译，它可能会运行，甚至可能会通过测试，但软件质量不仅仅是这些操作属性。我们希望我们的产品具有许多其他属性。我们需要开发健壮、可靠、可维护——并且可能可重用和可移植的系统——这些特性需要比原型设计期间更多的远见和更广阔的视野。原型设计的目的是探索一个想法或技术，或者演示一种能力、功能或界面——这与所描述的目标截然不同。
神话 3：行业已经认识到最佳实践的价值
我们在这里要考察的最后一个神话是方法论的采用。作为软件工程教授，我们有时会因为对软件开发世界的看法带有偏见和学术性而受到批评。我们提倡使用标准技术和方法论，而不考虑紧张的期限、消息不灵通的管理者或许多其他现实世界的问题。
当然，这不是真的。我们非常了解这些问题，这种理解源于我们自己在“行业”中的经验。我们集体在航空航天、企业系统和应用程序开发领域拥有25年的经验——无论是在行业还是学术界——都让我们接触到所有这些考虑因素：对预算和期限不切实际的期望、不合理的管理和不称职的员工、不断变化的需求目标、目标平台和技术。在所有这些情况下，当尝试时，临时方法都行不通。因此，我们意识到，除非遵循和推广最佳实践，否则行业将永远处于危机之中。认为临时的、随机的实践能够征服我们解决的问题的复杂性是根本站不住脚的。
不幸的是，许多人仍然试图捍卫这种立场，认为这些技术不起作用，它们花费的时间太长，或者它们扼杀创造力。无论是什么原因，令人恐惧的现实是，在许多开发工作中，都没有遵循系统的分析和建模方法。这从我们调查的回复中可以清楚地看出。首先，我们惊讶地发现，面向对象技术仅使用了30%的时间，特别是考虑到面向对象技术和语言的普及和看似的兴趣。然而，与我们发现最主要的做法竟然是根本没有做法相比，这种惊讶就显得苍白无力了——这种做法（如果可以称之为做法的话）是由整整三分之一的调查参与者报告的。
用寓言的方式来大谈特谈其他工程学科如何应对相应的复杂性和问题被认为是老生常谈，我们意识到软件开发带来的独特问题。但是请记住，我们并不是建议每个人都遵循特定的方法；我们不提倡所有项目都使用RUP（Rational Unified Process），所有组织都达到CMM（能力成熟度模型）5级，所有团队都使用XP（极限编程），或所有应用程序都使用面向对象。每个问题、组织和项目都有自己的特点，需要一系列的技术和策略——但绝不是没有！
揭穿神话
我们意识到，我们从结果中得出的意见是主观的和“局部的”。但结合真实的现实世界经验，我们必须得出不可避免的结论：编程美国并不都是美好的。
那么你能做些什么来帮助揭穿这些神话呢？ 更好的是，我们如何帮助根除这些过时的做法，以便这些神话成为无可辩驳的事实？ 首先，与自满情绪作斗争。努力成为反对那些屈服于惰性、拒绝改变和拒绝采用新方法论的庸才的倡导者。指出那些坚持使用过时方法的人——例如，旧的瀑布模型——或者那些拒绝采用健全实践的人，例如丢弃式原型。质疑那些看似显而易见的事情。
你能做的第二件事是成为变革的推动者。在你的组织内部努力采用适当的方法论。请记住，一种尺寸适合所有人的方法可能适用于购买袜子，但不适用于软件开发：需要一系列的解决方案和技术。推广健全的实践，特别是对你的资深同事，他们可能是过去的捍卫者。我们几乎想说推广“最佳实践”，但这可能是一个被过度使用的术语，可能捕捉到不切实际的理想。也许我们应该满足于“体面的实践”。幸运的是，你的新同事可能已经接受了更好的实践，而旧的方法正在被企业惯性逐渐摒弃。努力帮助他们保持对现代的尊重。
最后，当然，无知的真正敌人是启蒙。继续学习和调整实践，以整合过去、现在和未来的精华。
参考文献
1. 软件需求实践问卷：参见 http://www.personal.psu.edu/staff/c/j/cjn6/survey.html。
2. Neill, C. J., 和 Laplante, P. A. 需求工程：实践现状。IEEE Software 20, 6 (2003年11月/12月), 40–45; http://csdl.computer.org/comp/mags/so/2003/06/s6040abs.htm。
3. 参见参考文献 2。
4. Royce, W. W. 大型软件系统开发管理。IEEE WESCON 会议论文集 (1970年11月)。重印于第九届国际软件工程会议论文集 (1987), 328-338。
5. 参见参考文献 2。
6. Brooks, F. 人月神话，第二版。Addison-Wesley, New York: NY, 1995.
PHILLIP A. LAPLANTE，博士，是宾夕法尼亚州立大学大谷研究生院软件工程副教授。他的研究兴趣包括实时和嵌入式系统、图像处理和软件需求工程。他撰写了大量文章和17本书籍，共同创立了Real-Time Imaging，并编辑了CRC出版社的图像处理系列丛书。Laplante获得了史蒂文斯理工学院的计算机科学学士学位、电气工程硕士学位和计算机科学博士学位，以及科罗拉多大学的工商管理硕士学位。他是IEEE高级会员、和国际光学工程学会 (SPIE) 会员，并且是宾夕法尼亚州注册的专业工程师。
COLIN J. NEILL 是宾夕法尼亚大学软件工程助理教授。他的专业领域包括面向对象分析和设计、实时系统设计和电信。他拥有威尔士斯旺西大学的电气工程学士学位、通信系统硕士学位和实时系统设计博士学位。
最初发表于 Queue 第 1 卷，第 10 期—
在 数字图书馆 中评论本文
更多相关文章
Catherine Hayes, David Malone - 质疑评估非密码哈希函数的标准
尽管密码哈希函数和非密码哈希函数无处不在，但在它们的设计方式上似乎存在差距。存在许多由各种安全需求驱动的密码哈希标准，但在非密码方面，存在一定的民间传统，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布很有意义，但在面对具有特定模式的数据集时，这可能是一个挑战。
Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 在行动
随着领导者在财政紧缩和人工智能等变革性技术的背景下寻求优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。技术领导者直观地接受，良好的开发者体验可以实现更有效的软件交付和开发者幸福感。然而，在许多组织中，旨在改善 DevEx 的拟议计划和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过介绍使用基于代码、低代码和极限低代码技术进行的实验室实验结果，以研究生产力差异，从而为该主题提供新的见解。低代码技术已明确显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。
Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技巧来服务于商业和社会，但它也很健忘。在其快速前进的过程中，它会受到时尚潮流的影响，并且可能会忘记或忽略针对其面临的一些永恒问题的成熟解决方案。用例于 1986 年首次引入，并在后来普及，就是这些成熟的解决方案之一。
© 保留所有权利。