03 | 瀑布模型：像工厂流水线一样把软件开发分层化
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
瀑布模型是一种软件开发方法，将整个项目过程分成六个主要阶段：问题的定义及规划、需求分析、软件设计、程序编码、软件测试和运行维护。尽管现在已不是最主流的开发模式，但它仍然是软件开发中必不可少的基础，因为需求、设计、编码和测试这四项活动都源自瀑布模型。文章以一个网站开发项目为例，详细介绍了如何使用瀑布模型来开发软件项目，展示了瀑布模型在实际项目中的应用和挑战。瀑布模型的优点在于让软件开发过程有序可控、让分工协作变成可能、以及质量有保障。然而，瀑布模型也存在一些问题，最大的问题是不能及时响应需求变更，越到后期变更代价越大。因此，后来有很多人提出了其他的软件生命周期模型，以期保留瀑布模型的优点，克服其中存在的问题。文章总结了瀑布模型的价值相当于工业界第一次提出流水线作业，解决了软件项目开发中的几个重要问题。读者可以通过这篇文章深入了解瀑布模型的具体应用，以及在实际项目中可能遇到的问题和解决方法，对软件开发人员和项目经理来说是一份有价值的实践经验总结。
《软件工程之美》，新⼈⾸单¥59
全部留言(60)
- 最新
- 精选
纯洁的憎恶我对瀑布模型感触颇多啊！首先瀑布模型把复杂的软件生产过程，按照时间线索，切分为若干较为独立和专业的部分，条理清晰。在每个阶段内只需要集中精力与阶段任务即可，不用胡子眉毛一把抓。每个节点有交付件，过程可控、权责清楚明白。破布模型特别符合我所在的大型央企的性格。但是我经手好几个项目，也被瀑布模型折腾的死去活来。比如我现在正在处理的项目。 首先，从可行性分析、立项、批预算、采购建设单位就花了一年多的时间。可行性分析做了1个月，立项流程走了不到1个月，批预算的时候，主管业务的领导变卦了，要求重新做可行性分析，于是我们又花了1个月。二次立项的时候，主管信息的大领导突然决定要把区块链和人工智能等热门技术加进去，于是又要求重新立项。但是我们要做的事情实在和区块链八竿子打不着，死去活来的找了个理由扯上关系了，来来回回又花了2个月，这就半年了。再次走到批预算的环节，主管领导发现原来的预算干不了这么多事情，又不同意增补预算，于是继续扯皮。经过多番协调，总算解决了，这时候叶子已经黄了。 我们立刻开展需求调研，但各个需求部门和最终用户都借口工作太忙不搭理我们，我们只好自己憋需求，简直是闭门造车。等需求憋出来了，大领导把需求部门都叫来议一议，结果被集体口诛笔伐。大领导怒了，强令需求部门专门抽时间参与需求调研，各部门也是不情不愿啊，效果可想而知。需求总算审查通过了，就在我们准备采购实施单位的时候，国资委一直红头文件下来，公司的采购流程发生重大调整，项目被硬生生搁置下来。眼看年根了。。。 第一年就这么过去了。等来年采购流程也屡的差不多了，预算又出问题了。去年批的预算只能去年用，不允许跨年。只好等到年中调整预算，又小半年过去了。采购流程走完，实施单位也很够意思，不等合同签订就投入工作。我们用极短的时间完成了软件设计，并且开始如火如荼的开发工作，此时又到了金秋。就在这时，新的纪检书记上任了，他对我们的系统设计很不满意，要求相关部门限期整改，于是需求大调整，可是这会儿编码已经进行了1/3啦。。。之后就是上线日期一推再推，从10月初推到10月底，再推到11月、12月，眼看又要跨年了。我们和实施单位连续半年997，总算看到上线的曙光，这时候公司一把手退休了。。。 新领导上任后对整个流程极不满意，否定了纪检书记的指示，于是我们又开始第2伦大调整。现在已经是项目的第三年了，我们依旧没能上线。整个团队都要累趴下了，全公司一点成果也没看见。作者回复: 很感动，写了这么长的留言。这是个很生动的案例。像这样的环境，虽然说根源不是瀑布模型造成的，但是瀑布模型确实加剧了问题。 对于这种开发模式，邹老师在《构建之法》中有精彩的论述：“老板驱动的流程：笔者在和中国一些企业的软件开发者交流的时候，听闻不少人提到开发流程事实上是由行政领导主导，或者由公司的老板驱动，我们姑且把它命名为老板驱动的流程。” 领导“有极大权力， 极小责任”的驱动方式。 这种项目可以考虑调整为快速迭代的模式（下一篇会提到，核心就是控制每次的需求），尽早上线核心功能，上了慢慢改，下个迭代改。就像老话说的：“生米先煮成熟饭”。 还有PM应该要能顶得住压力，在一个迭代中应该不改或者少改，才能继续推进。 另外，也能理解这种项目不是靠个人就能改变太多的，适当的时候提一些建议，改变能改变的，接受不能改变的。 最后，有具体问题也欢迎继续留言讨论，很乐意提供建议：）
2019-02-28571
西西弗与卡夫卡瀑布模型分解和识别出了软件开发过程中的几种主要活动，以及每种活动所关注的价值点，并从时间尺度上划分了对应的阶段。这几个阶段形成了一个环。现代的其他软件工程方法，举个不太恰当的比喻，就像是滚动更快的轮子。不管什么样的轮子，这几个阶段的功夫，我们都得练好作者回复: 你这个比喻很有意思的👍，下一篇关于衍生模型的很多例子完全适应你这个比喻。 敏捷开发的Scrum可能还是有点不一样，每个Sprint并不完全按照这个周期，但是在一个Sprint的某个用户故事的开发，其实也适用于这个环。 所以你说的关于这几个阶段的功夫，确实都得练好！
2019-02-2816
王二宝我是非科班出身的程序员，工作第三年，真的觉得《软件工程》是门必须要掌握的学科。我们公司是几人小团队，很多流程都是自己摸索的，我今天才知道，原来我们平时的工作流程就是瀑布模型啊。让我想到了吴军的专栏中说，很多野路子探索了很久才恍然大悟，并以此骄傲的东西，对于有理论基础的人来说，这就是很平常的理论啊，甚至是觉得这东西，是与生俱来的。作者回复: 你这个总结的特别好👍 我以前不是科班的时候，就是怎么都想不明白大项目怎么开展，后来改专业到软件工程后，就觉得这是很自然而然的事情了。 而且虽然我们大学只讲了瀑布模型，但是后来再看迭代模型，马上就明白怎么回事了。当然也有科班也有问题，例如我刚开始对敏捷就有点不屑一顾，觉得瀑布模型就很好呀：）
2019-03-01311
一路向北目前我们的开发模式还是以瀑布型的为主。之前也引进过敏捷开发模式，但是因为团队不大，每个人的分工比较清楚，甚至经常是每个人负责一个项目，所以也就没有按照敏捷的那一套流程走。 我的理解是，如果产品的需求变化不大，产品设计者的前瞻性和设计能力比较强，设计的框架的伸缩性强，是不是瀑布式的开发会优于敏捷开发呢？也就是说，产品经理的需求分析能力，抽象能力很重要，而实际的实现人员相对要求会低一些？ 对于较大的项目，如果能做到合理的项目分割，划分，那么在分项目中再实行瀑布式开发，是不是效率也会挺高？作者回复: > “如果产品的需求变化不大，产品设计者的前瞻性和设计能力比较强，设计的框架的伸缩性强，是不是瀑布式的开发会优于敏捷开发呢？” 如果满足你说的前提，再加上没什么进度压力的话，瀑布模型像计划性、质量、过程控制都是很好的，是不是比敏捷开发好这个我不好随便下结论，因为敏捷开发理想情况下一样可以质量高。问题是绝大部分时候真的不是理想情况。 > 对于较大的项目，如果能做到合理的项目分割，划分，那么在分项目中再实行瀑布式开发，是不是效率也会挺高？ 是的，你说的这种大的拆小的是下一篇会讲的迭代模型，基于瀑布模型，但是更小，也更高效。在再下一篇我还会对比迭代模型和敏捷开发，希望能帮助你更好的理解其中的差别。 很多人不愿意尝试其他瀑布模型之外开发模式，可能是因为已经对瀑布模型太熟悉了，多看看多学习一下其他模型好的地方，再尝试实践也是很好的。
2019-02-2810- Felix实际工作中我举一个例子，倒逼项目往往就自然而然地使用了瀑布模型，而中间一些领导的"创意"或竞品的对齐导致需求变更，最惨的是瀑布的下游——开发和测试 的疯狂加班，请问宝玉老师对于倒逼项目有没有自己的处理方式和建议
作者回复: 通常两种方案： 1. 砍需求，以保证可以按时完成 2. 快速迭代，可以及时响应变更
2019-02-288 
Charles我们现在用的也基本是瀑布模型+小版本瀑布迭代，碰到需求变更也尽量放到下个版本拥抱，你文章的案例和留言中的案例看完，感触颇深似曾相识，精彩😄 几个点请教下老师： 1. 文中案例时间预估是老板给的，还有一种是老板或客户给个简单的需求和案例让预估时间，那么在瀑布模型下是否先要经历完需求分析以及架构设计阶段才能预估出时间了？能否给个预估时间好的实践？谢谢🙏 2. 瀑布模型非常考验人的能力，会造成互相扯皮推卸责任，上线以后有什么问题，还会互相推锅背，这种情况下管理者有啥好的方式去解决？老师有什么经验分享吗？谢谢🙏作者回复: 《10 | 项目计划：代码未动，计划先行》会讲时间估算。 通常时间估算并不需要特别精确，初步的需求分析就可以大致估算出每个阶段需要的时间。大致时间确定后，就可以设置里程碑。里程碑定了后再确定细的计划。 虽然我觉得甩锅不是什么好事，但是如果你真要甩锅，最简单有效就是设置流程去划分责任：） 上线后有问题其实很正常的，重要的是要有合理的机制： 1. 及时发现问题，监控报警、用户投诉反馈等 2. 马上解决问题，对线上版本有专门的代码分支，可以随时打补丁修复，测试上线 3. 避免后续再犯同样的错误。要分析原因，看什么导致问题，然后改进流程。 希望以上回答能解答你的问题，如果还有不清楚的欢迎继续留言。
2019-03-027
卡皮定了很多课程，宝玉老师是每条留言都回复的，赞一个！作者回复: 谢谢夸奖。 其实这就像上课，课后的答疑。毕竟一篇文章不可能面面俱到，难免有没讲到和没讲清楚的地方，通过留言和回复，可以把这些问题补充说明清楚。
2019-03-056- 纯洁的憎恶老师的留言区真是异彩纷呈啊😁
作者回复: 感觉大家项目经历都很丰富，一些内容触动了大家留言的想法💡 很喜欢看大家的留言，可以了解大家想要什么有什么问题，也可以了解到很多有意思的项目，根据留言还可以调整后面的内容呢。 谢谢
2019-02-286 
beyondzhao能不能问一下老师，现在行业使用较多的原型工具有哪些？是Axure吗？作者回复: 具体还是看什么应用，App还是Web还是其他，Web的话Axure应该是不错的选择。 如果是App我最近看到一个高保真的原型设计工具 framer 非常厉害： https://www.framer.com/
2019-03-065
tongmin_tsai老师，我经历不同的公司，因为在较传统的行业，基本都采用瀑布模型，但是不同的公司，在瀑布模型的流程上大体差不多，就是每个流程，像您里面说到的 问题的定义及规划 -》需求分析-》软件设计-》程序编码-》软件测试-》运行维护等阶段，输出产出不同的成果，大体就是不同的公司，每个阶段产出不一致，特别是问题的定义及规划 -》需求分析-》软件设计这些阶段，比如基本都是产出相应的文档，有些还产出如原型图，流程图或者一些UML相关的状态机图等等，不知道有没有业内比较好的实践模板可以提供参考的，有没有较为通用，符合中小型公司，或者对应中大型公司的模板，如果这些规范的较好，就不会造成有时文档五花八门的现象作者回复: 文档这部分，没有什么统一的模板。我的观点是，文档最关键的地方在于达到其目的，格式是其次的。 文档的目的我觉得主要是两点： 1. 写文档的过程中帮助你梳理清楚逻辑 2. 写出来的文档是要用来沟通的，让其他人通过文档明白你的思路 所以建议不用太在意格式，重点放在内容上就好了。
2019-03-015
