软件开发生命周期：教材里的瀑布模型与互联网公司的真实流程

学软件工程的时候，我们经常会看到一套很标准的流程：需求分析、概要设计、详细设计、编码、测试、维护。

但真正进入互联网项目组，你会发现大家嘴里说的更多是 PRD、原型图、UI 走查、接口联调、灰度发布、回滚预案。

这不是教材错了，也不是公司流程不专业。两者关注点不一样：教材讲的是软件生命周期的抽象模型，公司用的是围绕业务交付演化出来的协作流程。

先说明一下本文范围：这里说的“教材流程”，主要指软件工程里最经典、最容易入门的瀑布模型；这里说的“工程界流程”，主要指互联网产品团队的常见开发方式。银行核心系统、车载软件、军工、政务、医疗系统这类强合规项目，流程可能会更严格，也可能采用瀑布、V 模型、敏捷的混合方式。

一、教材里的经典流程：瀑布模型怎么拆阶段

瀑布模型的特点是阶段顺序清晰：先把需求说清楚，再做设计，再编码，再测试，最后上线维护。它强调每个阶段都有输入、输出和评审节点。

注意，瀑布模型不是“永远不能回退”。只是越到后面发现问题，回退成本越高。比如测试阶段才发现需求理解错了，修改就不只是改几行代码，而是可能连需求、设计、接口、测试用例都要一起改。

教材里的经典瀑布模型

1. 立项与可行性研究

这个阶段解决的是项目到底要不要做。

常见问题包括：

  • 技术上能不能实现
  • 成本和周期是否可控
  • 是否有足够收益
  • 是否存在合规或法律风险

常见产出：

  • 可行性研究报告
  • 项目立项说明
  • 初步成本与工期估算
  • 风险评估结论

2. 需求分析

这个阶段解决的是软件到底要做什么。

教材里通常会强调软件需求规格说明书，也就是 SRS。它会尽量把功能需求、非功能需求、边界条件、数据要求、异常场景写清楚。

常见产出：

  • 软件需求规格说明书
  • 用例说明
  • 数据需求说明
  • 需求评审记录
  • 需求跟踪矩阵

3. 概要设计

概要设计解决的是系统整体怎么搭。

它不会直接写到每个函数怎么实现，而是先确定系统骨架，比如模块怎么拆、架构怎么选、核心数据怎么流转、系统之间怎么交互。

常见产出：

  • 概要设计说明书
  • 系统架构图
  • 模块划分图
  • 数据模型草图
  • 接口概要说明

4. 详细设计

详细设计解决的是每个模块具体怎么实现。

到了这个阶段，设计粒度会更细，开发人员可以根据文档直接编码。比如数据库表结构、接口字段、关键流程、状态流转、异常处理都会被明确下来。

常见产出：

  • 详细设计说明书
  • 数据库表结构设计
  • 接口详细定义
  • 类图、时序图、流程图
  • 关键算法或业务规则说明

5. 编码实现

编码阶段就是把设计落成代码。

教材里这个阶段看起来很简单，但实际项目里会涉及编码规范、代码审查、单元测试、分支管理、构建脚本等内容。

常见产出：

  • 源代码工程
  • 单元测试用例
  • 开发自测记录
  • 代码评审记录
  • 可构建的软件版本

6. 测试验证

测试阶段解决的是软件是否符合需求，质量是否达到交付要求。

常见测试层次包括单元测试、集成测试、系统测试、验收测试。越靠后越接近真实业务场景，越能发现跨模块、跨系统的问题。

常见产出：

  • 测试计划
  • 测试用例
  • 缺陷清单
  • 测试报告
  • 验收报告

7. 运行与维护

软件交付上线后，并不代表生命周期结束。

真正投入使用后，还会出现环境变化、业务变化、缺陷修复、性能优化、安全加固、版本升级等问题。维护阶段通常是软件生命周期里最长的阶段。

常见产出：

  • 用户手册
  • 运维手册
  • 故障处理记录
  • 版本变更记录
  • 退役评估报告

二、互联网产品团队：一个版本通常怎么落地

互联网团队不是没有生命周期，而是把生命周期压缩进一个个版本里。

一个需求不会等一年才完整交付，而是会拆成多个版本，按周、双周、月度节奏迭代。每个小版本都要经历需求、设计、开发、测试、发布、反馈，只是文档更轻，协作更密，反馈更快。

互联网产品团队常见迭代流程

1. 立项与商业评估

工程里的立项不只是技术能不能做，更关心业务值不值得做。

产品负责人、业务方、技术负责人会一起判断目标、收益、成本、风险和优先级。对于大需求，还会提前做技术预研，避免产品方案定完后才发现技术成本不可接受。

常见产出：

  • BRD 或 MRD
  • 项目背景说明
  • 目标与指标
  • 人力与排期预估
  • 技术预研结论

2. 需求定义与交互原型

互联网团队不会只靠一份纯文字需求文档推进开发。

产品经理通常会写 PRD，同时给出页面流程、线框图或可点击原型。这样开发、测试、设计、业务方可以围绕同一个可视化对象讨论，减少“你以为”和“我以为”。

常见产出：

  • PRD
  • 页面流程图
  • 线框图
  • 可点击原型
  • 需求评审纪要
  • 需求优先级清单

3. UI / UX 设计

对于 C 端 App、Web 产品、运营活动页来说，UI 和 UX 是非常关键的独立环节。

设计师会基于原型输出高保真设计稿、组件状态、异常状态、空页面、加载态、动效说明等内容。开发并不是只看一张漂亮的图，而是要根据设计稿还原真实交互。

但要注意，纯后端系统、中间件、SDK、基础设施项目未必有 UI 阶段。它们的“设计重点”更多会体现在接口设计、架构设计、数据模型和运维方案上。

常见产出：

  • 高保真设计稿
  • 设计规范
  • 组件库说明
  • 标注与切图资源
  • 动效说明

4. 技术方案设计

这个阶段对应教材里的概要设计和详细设计，但互联网项目通常不会把两个阶段切得特别死。

常见做法是技术负责人先把核心方案说清楚：系统怎么改、接口怎么定、数据表怎么设计、是否影响老版本、是否需要灰度、是否有回滚方案。

常见产出：

  • 技术方案设计文档
  • API 接口文档
  • 数据库设计文档
  • 核心流程图
  • 兼容与灰度方案
  • 测试关注点

5. 开发、自测与联调

开发阶段不是每个人关起门来写自己的模块。

前端、后端、客户端经常需要并行开发。接口没完成时可能先用 Mock 数据，接口完成后再进入联调。联调是工程界非常真实的一环，因为很多问题不是单模块内部 bug，而是字段理解、状态流转、异常处理、版本兼容上的问题。

常见产出：

  • 可运行代码
  • 单元测试结果
  • 开发自测记录
  • 联调环境
  • 联调问题清单

6. 测试与 UAT 验收

测试团队会根据需求文档、原型、设计稿、接口文档编写测试用例，覆盖功能、兼容、性能、安全、异常场景等内容。

同时，产品经理或业务方会做 UAT，也就是用户验收测试。测试关注“有没有 bug”，产品和业务更关注“是不是我要的效果”。

常见产出：

  • 测试用例
  • 测试执行报告
  • 缺陷清单
  • 回归测试记录
  • UAT 验收结论

7. 灰度发布与上线

上线在教材里常被归到维护阶段，但在互联网团队里通常会被单独拎出来。

因为上线不是点一下发布按钮。稍微成熟一点的团队都会考虑灰度策略、监控指标、回滚预案、数据校验、用户影响范围。尤其是客户端、支付、账号、订单这类核心链路，更不可能无脑全量发布。

常见产出：

  • 发布计划
  • 灰度方案
  • 回滚预案
  • 部署记录
  • 上线验收单
  • 发布公告

8. 数据复盘与下一轮迭代

互联网产品上线后，真正的反馈才开始。

团队会看埋点数据、转化率、留存、崩溃率、接口耗时、用户反馈和客服问题。然后再决定是继续优化、补需求、修 bug，还是停止投入。

常见产出：

  • 版本发布日志
  • 数据复盘报告
  • 线上故障记录
  • 运营反馈
  • 下一轮需求池

三、横向对比：两套流程到底差在哪

教材流程和互联网流程不是简单的谁先进、谁落后。

教材里的模型更像“抽象骨架”，帮助你理解软件从想法到交付的基本阶段。互联网流程更像“团队协作手册”，把这些阶段拆成产品、设计、开发、测试、运维之间可以执行的动作。

教材流程与互联网流程对照

教材里的瀑布模型 互联网团队常见流程 主要差异
可行性研究 立项、商业评估、技术预研 教材更重论证完整性，互联网更重投入产出和优先级
需求分析 PRD、原型图、需求评审 教材偏文字规格说明，互联网会把需求可视化
概要设计 架构设计、模块划分、技术方案 教材强调系统结构，互联网强调能否支撑当前版本落地
详细设计 接口设计、数据库设计、核心流程设计 教材文档更完整，互联网更看重关键风险点是否说清楚
编码实现 开发、自测、前后端联调 教材偏单阶段描述，互联网更强调多人协作和联调成本
软件测试 功能测试、回归测试、专项测试、UAT 教材关注需求符合性，互联网还关注产品体验和业务验收
运行维护 灰度发布、监控、故障处理、持续迭代 教材把上线后统称维护，互联网会把发布和迭代单独管理

1. 流程逻辑不同

教材里的瀑布模型强调顺序推进，适合讲清楚每个阶段的职责和边界。

互联网产品流程更强调迭代推进。一个大需求会被拆成多个小版本，每个版本都走一遍小型生命周期。

2. 文档重心不同

教材更重标准文档，比如需求规格说明书、概要设计、详细设计、测试报告。

互联网团队也需要文档，但文档通常更轻，更贴近协作。PRD、原型图、接口文档、设计稿、发布计划、回滚预案，都是为了让团队尽快对齐并安全交付。

3. 角色分工不同

教材里的角色划分通常比较抽象，比如系统分析员、设计人员、程序员、测试人员。

互联网团队的角色颗粒度更细：产品经理、交互设计师、UI 设计师、前端、后端、客户端、测试、DevOps、运营、数据分析都可能参与同一个版本。

4. 适用场景不同

瀑布模型或偏瀑布的流程，更适合需求稳定、合同边界清晰、合规要求强、交付文档要求高的项目。

互联网迭代流程，更适合需求变化快、重视用户反馈、需要持续试错和快速发布的产品。

5. 真实项目经常是混合流程

很多公司并不是纯瀑布，也不是纯敏捷。

比如一个金融 App，需求立项和合规评审可能很瀑布；App 端页面优化可能很敏捷；底层支付链路又会非常严格，发布前要经过多轮灰度和审批。

所以不要纠结“到底哪套流程正确”。更现实的判断方式是：这个项目需求稳不稳定、风险高不高、合规强不强、反馈快不快。

四、给开发者的理解方式

如果你是开发者，可以这样理解两套流程：

  • 教材里的流程，是为了让你知道软件工程的完整骨架。
  • 公司里的流程，是为了让一个团队能把需求安全、稳定、可控地交付出去。
  • PRD 不是需求分析的替代品，而是需求分析在产品团队里的落地形式。
  • 原型图和 UI 稿不是“美工环节”，而是降低沟通成本的重要交付物。
  • 联调不是多余流程，而是跨端、跨系统协作时必然出现的质量关口。
  • 灰度和回滚不是运维小事，而是互联网产品降低上线风险的核心手段。

一句话总结：

教材教你软件生命周期的底层逻辑，公司教你多人协作时怎么把软件真正交付出去。

参考来源