Informatics 43 — 第九周课程笔记

涵盖 Lecture 17 与 Lecture 18："我们遵循什么流程来开发软件？（第 1、2 部分）"

目录

1. 我们现在在哪 — 从测试走向流程
2. 为什么我们需要流程 — 软件工程的固有困难
3. 模型是什么，又是用来做什么的？
4. 软件生命周期模型 — 目录总览
5. 边写边改（Build-and-Fix）
6. 瀑布模型（Waterfall）
7. 快速原型（Rapid Prototyping）
8. 增量模型（Incremental）
9. 螺旋模型（Spiral）
10. 统一软件开发过程（RUP）
11. 极限编程（XP）
12. XP 的十四条实践
13. 从 XP 到敏捷 — 敏捷宣言
14. 敏捷原则、Ziv 定律与 Scrum
15. 敏捷 — 优点、缺点与采纳情况
16. 全景图 — 八种模型横向对比
17. Quiz 9 / 期末考复习指南
18. 总结与记忆框架

1. 我们现在在哪 — 从测试走向流程

第七周和第八周都活在同一个活动里：质量保证与测试。上一讲收尾了白盒测试 —— 用从源代码导出的程序图来推导测试用例，挑选这些用例去命中不同类型的覆盖（节点、边、循环、条件、路径），并巡视了其他几类 QA 方法（检查 / 评审、形式化方法、静态分析）。

第九周一下子拉到最远。我们不再问怎么把某一个活动做好，而是开始问整个工作是如何被组织起来的：

整门课的脉络至此已经完整，而流程模型正是统筹底下一切的那一层元结构（meta-layer）：

两节课覆盖这块领地。Lecture 17（第 1 部分）讲为什么我们需要流程（软件工程本质上就是难的），定义什么是流程模型，并走完前五个模型 —— 边写边改、瀑布、快速原型、增量、螺旋 —— 并引入 RUP。Lecture 18（第 2 部分）深入讲 RUP，再到极限编程（XP）和敏捷（Agile），并把整个单元框在一条历史性的转变之上：从僵化、重量级、文档驱动的流程，转向轻量、敏捷的流程。

2. 为什么我们需要流程 — 软件工程的固有困难

出发的前提很直白：软件工程是难的，我们需要流程来帮忙。 本讲把这一点扎根在 Fred Brooks 的经典论文 《没有银弹》（"No Silver Bullet"）的论证里 —— 软件有一组本质性的属性（固有困难），任何工具或技巧都无法把它们变没。

在这四点之上，本讲还加了第五个动因：软件可能带来潜在严重甚至灾难性的后果（第七周那些失败案例 —— 波音 737 Max、Therac 类的危害、千年虫 —— 正是这里的背景）。

流程作为解药。 既然这些困难是本质性的，回应之道就是纪律，而不是某个魔法工具。软件是通过一个定义良好的流程被工程化出来的，这个流程的存在是为了：

• 确保我们做对的事、把事做对、并且不遗漏任何东西；
• 同时还要因地制宜 —— 不同的流程适合不同种类的软件、公司和情境。

⚠️ Brooks 的那句点睛之笔很可能是 quiz / 考试考点：流程不是银弹[Brooks，《没有银弹》]。Brooks 论证：没有任何单项进展 —— 无论在技术还是管理上 —— 能凭一己之力在十年内带来软件生产率、可靠性或简洁性上一个数量级的改善。流程帮我们管理固有困难，但消除不了它们。

3. 模型是什么，又是用来做什么的？

本讲首先消解"模型"一词的歧义，因为它在日常语言里带着两种含义：

所以一个软件流程模型就是对软件开发如何推进的一种简化表示 —— 它抽掉细节，抓住工作在高层次上的形状。

流程模型是用来做什么的？ 它可以扮演两种角色，同一个模型也可以两者兼任：

规范性 / 描述性这个区分值得分清楚：白板上一个规定"先需求再设计再编码"的流程模型，是在被规范性地使用；而一位研究者观察真实团队怎么工作、画出由此得到的流程，则是在描述性地使用模型。大多数真实的模型两种用法兼有。

4. 软件生命周期模型 — 目录总览

本课程覆盖八个生命周期模型。大致按历史顺序排列，它们也勾勒出一条从重量级 / 僵化到轻量 / 敏捷的宏观弧线：

本讲的组织主线（在 Lecture 18 的总结里被明确点出）是一条随时间发生的转变：从僵化、重量级、文档驱动的流程（瀑布、RUP）转向轻量、敏捷的流程（XP、Scrum、敏捷）。边写边改连这条弧线的起点都还排不上 —— 它是流程的缺席，是其他一切要反对的对象。

5. 边写边改（Build-and-Fix）

边写边改是退化的极端情形：没有需求阶段，没有设计阶段，没有计划。你就直接写代码，然后一直打补丁。

生命周期：

幻灯片上的示意图用两种箭头画出这个循环：实线箭头表示开发，虚线箭头表示维护（"修改直到客户满意"那个框自己绕回自己，维护箭头从运行模式回到修改）。

边写边改是衡量其他每个模型改进幅度的基准线。它唯一的优点 —— 你能立刻开始写代码 —— 也正是它在任何大型项目上崩溃的原因：没有需求、没有设计，复杂性、可变性以及协调众多开发者的需要，全都无处安放。

6. 瀑布模型（Waterfall）

瀑布模型施加一套严格、有序的阶段序列。每个阶段都被完整地做完（并形成文档）之后，下一个阶段才开始，就像水沿着一级级台阶往下流。

各个阶段：

在幻灯片的示意图里，实线（开发）箭头严格地一级级向下穿过各阶段，而虚线（维护）箭头则向上折回 —— 还有一个"需求变更"框反馈回各阶段，表示系统投入运行后的维护。

⚠️ 值得记的名言（很可能是考点）—— Clay Shirky 评 Healthcare.gov 上线（2013）："瀑布模型相当于各方共同立下的一个誓言：在真正干活的过程中，谁都不许学到任何东西。"（"The waterfall model amounts to a pledge by all parties not to learn anything while doing the actual work."）这一批评指出，瀑布把所有的学习都冻结在前期的需求阶段，并且禁止团队在发现 —— 他们总会发现 —— 计划本来就是错的之后再去调整。

7. 快速原型（Rapid Prototyping）

快速原型针对的是瀑布"用户参与有限"这个弱点。与其先在纸面上把需求锁死，不如构建并丢弃一个简单的原型 —— 一个快速、用完即弃的版本，它唯一的任务就是引出并验证用户真正想要什么。一旦这个原型完成了使命，你就把它扔掉，再去开发真正的系统。

生命周期：

"构建并丢弃简单原型"这个框替换掉了一个在其余部分都像瀑布的流程开头的需求阶段；图的其余部分用的是同样的开发 / 维护箭头和"需求变更"反馈。

幻灯片上的两句名言道出了原型法为什么有用：

"人们在你把东西摆到他们面前之前，并不知道自己想要什么。" — Steve Jobs

"人们在见到自己不想要什么之前，并不知道自己想要什么。" — Humphrey 定律

关键词是丢弃。原型是一件学习工具，而不是产品的第一个版本。把它廉价地造出来、又愿意把它扔掉，才让团队能在投入一次完整而昂贵的构建之前，把隐藏的或被误解的需求暴露出来。

8. 增量模型（Incremental）

增量模型把系统分块（增量）交付，而不是一次性全部交付。你先把需求和高层架构做一遍，然后反复地一次构建、测试、发布一个增量。

生命周期：

中间那个"对每个增量"框写着：进行详细设计、实现与集成。测试。交付给客户。 另一张幻灯片把这一过程可视化成一段下行的阶梯：分析 → 设计 → 实现 → 测试 → 部署 → 维护，每一段阶梯产出 Release 1、Release 2、Release 3、…… Release n。

案例 — 微软改进它的流程：

增量是第一个让客户尽早且经常看到可工作软件的模型。这种早期反馈是它最大的优势 —— 而这正是同一种直觉，再过几个模型，XP 和敏捷会把它推向极致。

9. 螺旋模型（Spiral）

螺旋模型（Boehm）是风险驱动的。开发沿着一条螺旋绕圈推进；每一圈的开头都做风险分析，而这一圈里所采取的步骤是可变的，取决于风险分析发现了什么（某一圈可能是一次快速原型，或一份规格说明，或一次设计，或一次实现 —— 然后跟一个"验证"步骤）。风险最高、最不确定的部分被最先啃下来。

幻灯片上的示意图画出一条逐圈扩张的螺旋，每一圈都以风险分析开始、以验证结束，内层活动标注为快速原型？/ 规格说明？/ 设计？/ 实现？ —— 那些问号强调究竟做哪个活动，是由风险分析决定的，而非事先固定。

Boehm 的十大软件风险（展示了其中六条），及其管理技术：

（改编自 Hans Schaefer 的 "Software Risk Management: A Calculated Gamble"。）

螺旋的标志性动作是把风险前置。瀑布先做容易、好理解的需求工作，到很晚才发现难题；螺旋则刻意先去攻坚那些吓人、不确定的部分，好让一个注定失败的项目早早失败，而不是在投入数年之后才失败。

10. 统一软件开发过程（RUP）

RUP 是一个重量级、高度结构化的迭代式流程，由三个特征定义：

• 用例驱动（Use case driven） —— 开发围绕用例（用户想要完成什么）来组织。
• 以架构为中心（Architecture centric） —— 系统架构是一个核心的、一等公民式的工件。
• 迭代且增量（Iterative and incremental） —— 在一轮轮迭代中构建，每一轮都增加一部分能力。

RUP 模型是一个二维结构（那张著名的"驼峰"图）：

图上的两句说明道出了核心思想：

• "工作流在逻辑上把活动归类" —— 每个工作流是一类连贯的工作（例如，与需求有关的一切）。
• "在一次迭代中，你会走过所有工作流" —— 在单次迭代里你会触及每一个工作流，但每个工作流投入的工作量会随阶段而变化（那些彩色的"驼峰"在早期对需求很高，在中期对实现很高，在接近尾声时对部署很高）。

本讲还展示了三个详细的 RUP 工作流作为示例，说明 RUP 提供了多少指导：架构分析（Architectural Analysis）、分析与设计（Analysis & Design）、用例分析（Use Case Analysis）（每一个都是自成一体、关于角色、活动和工件的精细图）。

RUP 是重量级传统的最高水位线：庞大、规范性强、有工具支持、面面俱到。它的优点（指导、工具）和缺点（重量级、复杂）是同一枚硬币的两面 —— 而正是 RUP 这类流程的沉重，催生了 XP 和敏捷的反抗。

11. 极限编程（XP）

XP（Kent Beck）是对瀑布以及其他重量级 / 传统流程一次刻意"极端"的反动。本讲列出了 XP 所反对的那些传统流程的问题：

• 开发周期冗长
• 无力应对变化的需求
• 假设在项目开始之前需求就已被完全理解
• 过度依赖英雄式的开发投入
• 方法论复杂
• 工作的浪费 / 重复

（幻灯片字面上用一个巨大的红色 X 把这些划掉，传达出：XP 拒绝这一切。）

XP 的流程步骤：

1. 确定想要的功能（以用户故事（story）的形式）。
2. 估算、排优先级、细化这些故事。
3. 实现 / 交付每项任务 —— 通常采用测试驱动开发和结对编程。
4. 全程遵循 XP 的价值观与原则（见 §12）。

XP 的精神：把传统流程当作偶尔为之或项目末期才做的活动 —— 测试、集成、设计评审、客户反馈 —— 改成一直做、以极小的增量做。"极限"意味着把每一项好的实践都调到最高频率。

12. XP 的十四条实践

XP 由一组相互强化的实践与原则定义：

TDD 循环（红-绿-重构）：

XP 的嵌套反馈回路在所有时间尺度上同时运转：

考试时你不需要把这十四条全背下来。要知道 XP 是一束轻量实践，并能说出几条招牌实践 —— 结对编程、测试驱动开发、小版本发布、持续集成、简单设计 —— 并解释它们如何相互强化，共同服务于 XP 那个频繁、低风险、富含反馈的交付目标。

13. 从 XP 到敏捷 — 敏捷宣言

敏捷（Agile）是 XP 帮助催生的那个更宽广的哲学。它包含并演化自 极限编程、Scrum、Crystal、Kanban 等等。

它的奠基文件是 《敏捷宣言》（The Agile Manifesto，2001），行文为"我们逐渐认识到……更有价值" 的一组四项权衡：

⚠️ 这四条价值陈述是头号考点。关键的微妙之处在于：宣言说左边的项更被看重，但"右边的项仍然有价值"。敏捷并不是说文档或计划一文不值 —— 它是说，当它们与可工作的软件和响应力发生冲突时，左边的赢。

14. 敏捷原则、Ziv 定律与 Scrum

一些敏捷原则（本讲的选取）：

• 欢迎需求变化 —— 即便在开发后期也如此。
• 业务人员与开发者在整个项目中每天一起工作。
• 围绕积极主动的个体来组建项目 —— 信任他们能把事情做成。
• 面对面交谈是传递信息的最佳方式。
• 文档只是达成目的的手段 —— 它本身不是目的。
• 可工作软件的持续交付。

Ziv 定律 —— 敏捷立场的理论依据：

Ziv 定律说不确定性在软件工程的流程和产品中是内在且不可避免的。这是对瀑布核心假设（需求可以在前期被完全理解）的直接反驳：如果不确定性永远无法被消除，那么一个拥抱变化的流程，就会胜过一个试图把计划冻结的流程。

Scrum —— 最流行的敏捷框架。本讲是通过一段"Scrum 十分钟讲明白"的短视频引入它的，而非用大量幻灯片深讲，但它所覆盖的词汇值得知道：

考试提示：Scrum 拿到的是一段视频，而非一节详尽的讲解 —— 所以期望的是认得这些词汇、并知道 Scrum 是一个敏捷框架，而不是对各项仪式的深入演练。

15. 敏捷 — 优点、缺点与采纳情况

行业采纳情况（并排展示两项调查）：

Stack Overflow 开发者调查 2018 ——"开发者使用哪些方法论？"（多选，58,981 份回应）：

Kassab 等人，"Software Testing: The State of the Practice"，IEEE Software，2017 —— 最能描述每个项目的那一种方法论：

数据把整个单元的故事讲完了：敏捷和 Scrum 主导着实践，而重量级、文档驱动的流程（瀑布、RUP / 统一过程）已经萎缩成一小撮少数。这就是"从重量级转向轻量"这条弧线背后的经验证据。

16. 全景图 — 八种模型横向对比

17. Quiz 9 / 期末考复习指南

这是本课程最后一个内容单元 —— 下一节课是全课总结、期末考复习，以及一次不计分的迷你练习 quiz。下面的一切都可能考。

17.1 你必须能定义的词汇

17.2 四大固有困难（Brooks）

复杂性、一致性、可变性、不可见性 —— 软件工程为什么本质上就是难的。外加：流程不是银弹（Brooks）。

17.3 八种模型，按顺序

边写边改 → 瀑布 → 快速原型 → 增量 → 螺旋 → RUP → XP → 敏捷。要能给出每一个的核心思想、一个优点和一个缺点，并能把某个模型匹配到某个场景（例如，需求不确定且复杂 → 螺旋或原型法；需求稳定、明确 → 瀑布；小团队、需求会变 → 敏捷 / XP；安全攸关、大团队 → 不要用纯敏捷）。

17.4 那些名言（背下原文措辞）

17.5 RUP 的细节

三个特征（用例驱动、以架构为中心、迭代且增量）；四个阶段（初始、细化、构造、移交）；在一次迭代中你会走过所有工作流这个观念；优点（指导、工具、风险驱动）与缺点（重量级、复杂）。

17.6 XP 与敏捷的细节

XP 是对重量级流程的一次反动；要知道那些招牌实践（结对编程、TDD、小版本发布、持续集成、简单设计）以及 TDD 红-绿-重构循环。要知道《敏捷宣言》的四条价值（以及右边的项仍有价值这个微妙之处）、几条敏捷原则，以及 Scrum 是最流行的敏捷框架。

17.7 那条大弧线 + 数据

要能陈述从重量级 / 文档驱动转向轻量 / 敏捷这条转变，并引用调查证据（敏捷约 85%、Scrum 是最常见的单一方法论；瀑布 / RUP 如今已是少数）。

18. 总结与记忆框架

Week 9 knowledge structure
|
+-- The question this week
|   +-- "What process do we follow to develop the software?"
|   +-- A software life cycle model = a HIGH-LEVEL process
|       (model = simplified representation, not "ideal")
|   +-- Used PRESCRIPTIVELY (enforce rules) or DESCRIPTIVELY (characterize)
|
+-- Why we need processes (Lecture 17)
|   +-- SE is hard -- Brooks's essential difficulties:
|   |     Complexity, Conformity, Changeability, Invisibility
|   |     (+ potentially disastrous consequences)
|   +-- Process = do the right things / do them right / forget nothing
|   +-- NOT a silver bullet  [Brooks, "No Silver Bullet"]
|
+-- The five "classic" models (Lecture 17)
|   +-- Build-and-fix : code -> patch; tiny programs only
|   +-- Waterfall     : Req->Design->Impl->Integration->Test->Ops->Retire
|   |                   rigorous + documented; rigid; bad w/ ambiguity
|   |                   (Healthcare.gov; Shirky quote)
|   +-- Rapid prototyping : build & DISCARD prototype to learn reqs
|   |                       (Jobs; Humphrey's Law)
|   +-- Incremental   : deliver in pieces (Release 1..n)
|   |                   (MS: Win8 "Ta-da" -> Win10 iterative + A/B)
|   +-- Spiral        : RISK-DRIVEN; riskiest parts first; variable steps
|                       (Boehm's top-10 risks); end may not be known
|
+-- Heavyweight peak (Lecture 17->18)
|   +-- RUP : use-case driven + architecture-centric + iterative/incremental
|             4 phases: Inception, Elaboration, Construction, Transition
|             workflows x iterations ("humps")
|             strong: guidance/tooling | weak: HEAVYWEIGHT, complicated
|
+-- The lightweight revolt (Lecture 18)
|   +-- XP : extreme reaction to heavyweight processes
|   |        14 practices (pair programming, TDD, small releases,
|   |        continuous integration, simple design, ...)
|   |        steps: stories -> estimate/prioritize -> deliver -> values
|   +-- Agile : umbrella (XP, Scrum, Crystal, Kanban, ...)
|   |   +-- Manifesto (2001): individuals>process, working sw>docs,
|   |   |   collaboration>contracts, responding>plan (left valued MORE)
|   |   +-- Ziv's Law: uncertainty is inherent & inevitable
|   |   +-- Scrum: sprints, backlogs, standups, burndown, retrospectives
|   +-- Strengths: satisfaction, adaptable, good small teams
|       Weaknesses: few docs, unstable reqs, tech debt;
|       not for large / safety-critical / no-customer projects
|
+-- The big arc + data
    +-- SHIFT: rigid/heavyweight/document-driven -> lightweight/agile
    +-- Surveys: Agile ~85% (SO 2018); Scrum #1 single method (Kassab 2017);
        waterfall + RUP now a minority

一句话总结

因为软件工程本质上就是难的（Brooks 的复杂性、一致性、可变性、不可见性），而且没有任何流程是银弹，团队便采用一个软件生命周期模型 —— 一个被规范性或描述性地使用的高层次流程 —— 而这些模型沿着一条清晰的弧线演化，从僵化、重量级、文档驱动的方法（边写边改 → 瀑布 → 快速原型 → 增量 → 螺旋 → RUP）走向轻量、反馈驱动、拥抱变化的方法（XP → 敏捷 / Scrum），这一转变如今已被调查证实 —— 在实践中敏捷和 Scrum 占据主导，而瀑布和 RUP 已沦为少数。