瀑布模型
1970年，一位美国计算机科学家，得克萨斯州奧斯汀市洛克希德软件技术中心主任，温斯顿·沃克·罗伊斯（Winston Walker Royce）博士发表了一篇名为《管理大型软件系统的开发》的论文。
这篇论文在业界首次提出了软件开发过程中所能采取的几种不同的项目管理方式，其中就包括了我们目前所熟知的瀑布模型、迭代模式和敏捷模式。
在温斯顿博士所处的年代，面向过程的软件开发方式是业界主流，且那时的软件行业远没有现在先进，软件项目大多数也都属于航空航天、科研制造、军事系统、能源化工等类别，工程化的特色非常明显。
所以，软件开发的过程也就自然而然地参照、模仿了其他行业项目管理的方法，尤其是建筑行业中的项目管理经验。例如，建筑行业就把盖房子的过程分为策划、勘查、设计、施工、验收和交付等一系列阶段。
一个软件项目本质上和建筑项目没什么不同，都是一群人在那搬砖，也都是做计划、设计，然后实施、检测和交付，也有所谓的生命周期（Life Cycle）。
上图中的软件项目的生命周期包括这几个阶段。
问题定义阶段，在项目的一开始就要明确地知道需要解决什么样的问题。所以需要做好需求收集和分析、制定问题定义文档、确定项目目标和约束条件、编写可行性研究报告、制定项目计划、评估项目风险、与利益相关者沟通等工作。问题定义阶段的工作对于项目的成功至关重要，宁可多花一点时间在这上面（从个人教训来说，这一点怎么强调都不为过）。这一阶段非常重要的输出文件就是《可行性研究报告》。需求分析阶段，在搞清楚了要解决什么问题、可行性以及可能面临的风险之后，接下来就要进一步细化那些比较宏观的需求了，比如，开发一个电商系统。所以，在需求分析阶段通常会做下面几件事情：需求分析、制定需求规格说明书、评审和确认需求等。《需求规格说明书》对于开发工程师来说，是除了原型文档之外最重要开发文档之一，基本上可以起到字典和手册的作用。软件设计阶段，有了明确的需求，接下来不是忙着开发，而是先要做一些技术预研和技术选型，也就是采用什么样的技术栈（例如用J2EE、LAMP还是Python + Django/Flask），选择什么样的软件架构（例如MVC或整洁架构）等，为后续的编码工作铺路。该阶段通常会进行以下工作：系统架构设计、模块设计、数据及表结构设计、界面设计、性能设计、接口设计以及设计评审，然后输出《概要设计文档》，它是软件化的《需求规格说明书》，是指导工程师们开发的规范性文件。功能编码阶段，这一阶段的工作就是写代码。当然，除了写代码以外，还需要做微服务集成、单元测试、代码检查、版本管理、和性能调优等工程化的辅助工作，因为编写高质量的代码对于确保软件系统的稳定性、可靠性和性能至关重要。良好的编码实践和团队协作可以提高代码的质量和效率，有助于项目按计划顺利进行。系统测试阶段，这个阶段会对整个软件系统进行全面的测试，验证系统是否符合需求规格说明文档的要求，发现和修复可能存在的缺陷和问题。测试工程师们通常会执行：测试计划制定、测试用例设计、测试环境搭建、执行系统测试、管理软件缺陷、测试报告编写、协助用户验收等工作。部署维护阶段，这是软件开发生命周期的最后一个阶段，开发完成之后将软件服务部署到生产环境并持续维护它的正常进行。在部署运维阶段会展开以下的工作：部署计划制定、部署环境准备、软件安装部署、性能监控和优化、日常运维及异常排查、版本更新和升级，这个阶段其实也是成本最高，最让工程师们头疼的一个阶段。
瀑布模型作为一种软件开发生命周期模型，它就像瀑布那样，上一阶段的输出作为下一个阶段的输入，依次进行下去，直到最终的软件交付。
瀑布模型是一种传统的开发模型，但 传统不代表落后 ，它适用于那些需求一旦确定就极少变化，且对项目目标和成本的控制都非常严格的大型软件项目，例如电子政务、智慧城市、能源、化工、银行、电力等。
因为在大型的软件研发团队中，人员情况往往较为复杂多变，瀑布模型虽然呆板不够灵活，但它可以制定一个分工明确、时间清晰的工作流程，使得进入团队的新人能够快速了解当前的工作状况，大大降低了协同工作时的复杂度和沟通成本。
而且瀑布模型中的《需求规格说明书》、《概要设计文档》、单元测试和版本管理等输出文档，即使是不用瀑布模型开发，也同样可以借用。
只不过在追求极致速度的互联网应用中，瀑布模型已经OUT了。
感谢支持
更多内容，请移步《超级个体》。