01 · 软件过程模型（Software Process Model）

📅 预计 45 分钟　|　⭐ = 核心概念　|　📌 中英术语见文末
✍️ 配套练习：课程中心「软件工程」模块在线测验

1.1 软件危机：为什么写代码也会"翻车"

没有图纸就盖楼

把一次大型软件开发想象成盖一栋写字楼：瓦工（程序员）力气大、动作快，但如果从一开始就没有图纸、没有施工顺序、地基都没打就开始砌墙，楼盖到一半大概率要推倒重来，钱和工期全部打水漂。

20 世纪 60—70 年代，软件界就真实地撞上了这堵墙，人们把它叫做软件危机（software crisis）。

软件危机的四种典型表现 ⭐：

表现 说明 生活类比
进度延期 计划一年，实际三年 说好半年搬新房，三年还住工棚
成本超支 预算一路追加 装修预算从 20 万涨到 60 万
质量低劣 bug 多到修不完 墙刚砌好就裂
难以维护 加个功能牵一发动全身 想加一个插座，得把整面墙凿开

典型例子：IBM 的 OS/360 操作系统，投入数千人年，交付后依然缺陷累累，延期多年。它让整个行业意识到：光靠个人英雄式的"高手写代码"，撑不起大型软件。

危机的根源不只是"人不努力"，而是方法问题：

  • 规模爆炸：从几千行膨胀到几十万、几百万行，靠脑子记不住全部细节。
  • 需求说不清：用户说"要一个管理系统"，到底管什么、管多细，谁也答不上来。
  • 轻视设计与测试：拿到需求直接敲代码，跳过设计，后期返工成本翻倍。
  • 缺乏过程管理：没有统一的活动顺序、交付标准和质量检查点。

💡 记忆口诀：软件危机四宗罪 = 延期、超支、烂质量、难维护。

⚠️ 常见错误

  1. 把软件危机理解成"代码写错"：它不是某个 bug，而是大型项目在进度、成本、质量、维护四个维度的系统性失控。
  2. 只记现象不记根源：考试常问"危机产生的原因"，要答出规模、需求、方法、管理这些层面，而不是"程序员不努力"。

1.2 软件过程：给开发装上流水线

从"手工作坊"到"生产流程"

做一道菜可以随性发挥，但开一家餐厅必须定流程：买菜→备菜→炒制→出餐→洗碗，每一步谁负责、验收标准是什么，写清楚。软件过程（software process）就是这个道理——它是开发软件的一套活动、方法和约束的集合。

经典软件过程包含四个基本活动 ⭐：

  1. 软件规格说明（specification）：定义要做什么（需求）。
  2. 开发（development）：设计并实现这个软件（设计 + 编码）。
  3. 验证（validation）：确认软件符合需求（测试）。
  4. 演化（evolution）：上线后继续改进、适应新需求（维护）。

过程模型（process model）回答的是：这四类活动按什么顺序做、能不能反复回退、每阶段产出什么。不同的模型就是不同的组织策略，没有绝对好坏，只有合不合适。

⚠️ 常见错误

  1. 把"过程"和"模型"混为一谈：过程是活动集合，模型是活动的组织方式（顺序/反馈策略）。
  2. 以为过程模型可以随便换：项目中途频繁切换模型等于没有模型，管理混乱成本更高。

1.3 瀑布模型：一条道走到黑

像瀑布一样只能往下流

瀑布模型（waterfall model）是最经典、也最好理解的过程模型：阶段像瀑布一样逐级而下，不回头。

需求分析 → 概要设计 → 详细设计 → 编码实现 → 测试 → 运行维护
（每阶段结束都有一个"评审/文档"检查点，通过才能进入下一级）

特点 ⭐：

  • 文档驱动：每一阶段都必须产出正式文档（需求规格说明书、设计文档等），文档是阶段完成的唯一凭证。
  • 阶段明确：上一阶段结束、评审通过后，才进入下一阶段。
  • 基本不回退：发现问题原则上返回上一阶段修改，代价随阶段后移急剧增大。

优点：阶段清晰、文档完整、便于管理和分派人员；适合对文档、审计要求高的项目。

缺点 ⭐：

  • 用户很晚才能看到可运行的程序，等发现问题往往已经晚了。
  • 需求变更代价巨大：需求错了要一路回退到开头。
  • 早期隐藏的错误会逐级放大，到测试期集中爆发。

适用场景：需求明确、稳定、变化少的项目，例如嵌入式系统、航天军工、政府合规项目。

💡 记忆口诀：瀑布 = 一泻千里不回头，文档是门票，变更要命。

⚠️ 常见错误

  1. 把瀑布说成"唯一正确"：它只适合需求稳定的项目，需求多变的项目用瀑布是灾难。
  2. 忽略"文档驱动"：瀑布每阶段产出的是文档，而不是可运行代码，这正是它"晚见成果"的根源。

1.4 迭代模型与增量模型：分批交付

迭代是"越来越厚"，增量是"越拼越全"

这两个概念最容易混淆，用一个比喻拆开 ⭐：

  • 迭代（iterative）：像反复涂一张画。每次"分析→设计→实现→测试"完整走一圈，整张画的每个部分都更精致一点，越画越厚、越完善。
  • 增量（incremental）：像拼拼图。按功能把系统切成一块块，每次交付一块能独立使用的功能子集，拼一块、用一块，越拼越全。

螺旋模型（spiral model）是迭代思想的代表：每圈迭代都先做风险分析，再确定目标、制定方案、开发验证，四步循环，风险大的问题尽早暴露。它特别适合风险高、规模大的项目。

迭代与增量常常结合使用：每轮迭代把系统整体做深一点，同时把已完成的功能增量交付给用户先用。

维度 迭代 增量
切分方式 纵切：每次完善整体 横切：每次完成部分功能
用户可见成果 每轮都有更完整的骨架 每轮新增一块可用功能
典型代表 螺旋模型 增量交付

⚠️ 常见错误

  1. 把迭代和增量当成同一个东西：一个是"反复精化"，一个是"分批拼装"，定义题的高频混淆点。
  2. 以为迭代就是"重复开发"：迭代每一轮都产出更完善的版本，不是原地打转。

1.5 敏捷开发：拥抱变化

敏捷宣言：四个"高于"

2001 年，一批软件方法论专家发布敏捷宣言（Agile Manifesto），提出四大价值观 ⭐：

  1. 个体与互动 高于 流程与工具
  2. 可工作的软件 高于 详尽的文档
  3. 客户合作 高于 合同谈判
  4. 响应变化 高于 遵循计划

翻译成大白话：别抱着厚厚的文档闭门造车，赶紧做出能跑的东西，让客户尽早试用，需求变了就变。

敏捷的十二条原则要点：小步快跑、持续交付可用软件、欢迎需求变化、业务人员与开发每天沟通、面对面交流、可持续的开发节奏等。

三种主流敏捷实践 ⭐：

实践 核心思想 关键要素
Scrum 固定长度迭代（Sprint） 三个角色、四类会议、产品待办列表
极限编程 XP 把良好实践做到极致 结对编程、TDD、持续集成、简单设计
看板 Kanban 可视化流程、限制在制品 看板墙、拉动式、WIP 上限

Scrum 的三个角色：产品负责人（Product Owner）决定做什么、排优先级；Scrum Master（流程教练）扫清障碍、维护流程；开发团队自组织地完成 Sprint 目标。

Scrum 的典型会议：Sprint 计划会（本轮做什么）、每日站会（15 分钟同步进展与障碍）、Sprint 评审会（向客户演示成果）、Sprint 回顾会（总结改进）。

XP 的两大标志：结对编程（pair programming，两人一台机器轮流写与审）、测试驱动开发（TDD，先写失败的测试，再写代码让它通过，最后重构）。

💡 记忆口诀：敏捷关键词 = 快、活、人。快（小步快跑）、活（拥抱变化）、人（个体与互动优先）。

⚠️ 常见错误

  1. 把"敏捷"理解成"没有文档、没有计划"：敏捷只是弱化过度文档，照样有评审、有迭代计划，只是更轻。
  2. 把 Scrum 和 XP 混为一谈：Scrum 管"节奏与角色"，XP 管"工程实践"，两者可以同时用。
  3. 记错宣言顺序：四价值观是"前者高于后者"，不是"前者取代后者"。

1.6 DevOps：让开发和运维打通

敏捷解决了"开发↔用户"，DevOps 解决"开发↔运维"

很多项目死在最后一步：开发写好的代码，运维不会部署、环境对不上、上线即事故。DevOps（Development + Operations）主张把开发和运维的流程、工具、目标打通，靠自动化消灭"你写的代码，我不管跑"的断层。

DevOps 的核心实践 ⭐：

  • 持续集成 CI（continuous integration）：代码频繁合并到主干，每次合并都自动构建、自动测试，问题早发现。
  • 持续交付/部署 CD（continuous delivery/deployment）：通过自动化流水线，把构建产物一键发布到测试、生产环境。
  • 基础设施即代码 IaC（infrastructure as code）：服务器、网络、数据库用代码声明和管理，环境可重复创建。
  • 监控与反馈闭环：上线后持续监控性能与错误，反馈回开发，形成"开发—部署—运维—改进"的循环。

典型流水线：编码 → 构建 → 自动化测试 → 打包 → 发布 → 部署 → 运维监控 → 反馈。

与敏捷的关系：敏捷是"开发侧"对需求变化的响应；DevOps 把这种快节奏延伸到上线与运维，让"持续交付"真正落地。

⚠️ 常见错误

  1. 把 DevOps 当成一个工具或一个岗位：它是文化 + 流程 + 自动化工具的组合，不是装个 Jenkins 就算 DevOps。
  2. 混淆 CI 与 CD：CI 是"频繁集成 + 自动测试"；CD 是"自动发布部署"。CI 在前，CD 在后。
  3. 以为 DevOps 取代了敏捷：两者互补，一个对内管迭代，一个对外管交付运维。

📌 双语术语表（本讲）

中文 English 记忆点
软件危机 software crisis 延期/超支/低质/难维护
软件过程 software process 活动 + 方法 + 约束
过程模型 process model 活动的组织方式
瀑布模型 waterfall model 逐级而下不回头
迭代模型 iterative model 反复精化整张画
增量模型 incremental model 一块块拼图
螺旋模型 spiral model 每圈先做风险分析
敏捷开发 agile development 拥抱变化
敏捷宣言 Agile Manifesto 四条价值观
产品负责人 Product Owner 决定做什么
冲刺/迭代 Sprint 固定长度迭代周期
极限编程 eXtreme Programming (XP) 结对 + TDD
结对编程 pair programming 两人一台机器
测试驱动开发 test-driven development (TDD) 先测试后代码
持续集成 / 持续交付 CI / CD 自动集成 / 自动发布
DevOps Development + Operations 开发运维一体化

⭐ 本讲考点清单

  1. 软件危机的四种表现：延期、超支、低质、难维护。
  2. 软件过程的四个基本活动：规格说明、开发、验证、演化。
  3. 瀑布模型：文档驱动、逐级而下不回退；优点文档完整，缺点变更代价大、晚见成果；适合需求稳定的项目。
  4. 迭代（反复精化整体）vs 增量（分批拼装功能）的区别。
  5. 螺旋模型每圈迭代先做风险分析，适合高风险项目。
  6. 敏捷宣言四条价值观：人 > 流程、可用软件 > 文档、客户合作 > 合同、响应变化 > 计划。
  7. Scrum 三个角色（产品负责人 / Scrum Master / 开发团队）与四种会议。
  8. XP 的两大标志：结对编程、测试驱动开发（TDD）。
  9. DevOps 核心：CI/CD、基础设施即代码、监控反馈闭环。