波仔
💻 第十二章 SE负责监管计算机系统的构建
📄 一句话概括

每个阶段有固定动作与固定交付文档——需求规格书、设计书、源代码、测试报告、操作手册，文档就是阶段间交接的绳结。

📝 本节和前面几节的关系

瀑布的六级各干什么、交什么差？本节把每个阶段的工作内容与交付文档对齐成表。

一、六站各干什么

需求定义：弄清【要解决什么问题】——访谈客户、梳理业务、定系统边界； 外部设计：定【系统长什么样】——界面、接口、与其他系统的对接方式； 内部设计：定【内部怎么实现】——模块划分、数据库设计、处理流程； 制作：照图施工写程序，配套单元测试；测试：证明系统正确；运用维护：上线、保养、持续改进。

二、文档为什么是验收凭证

阶段做没做完，不能靠【我感觉差不多了】——要靠交付文档说话； 每站文档各有其名：需求规格说明书、外部设计书、内部设计书、源代码与测试记录、测试报告、操作手册； 文档是阶段之间交接的绳结：下游照文档施工，验收照文档比对——没有它，返工与扯皮接踵而来。

三、上游文档是下游的施工图

需求书含糊 → 设计跑偏；设计书含糊 → 编程返工——问题总是下游爆发、根子在上游； 所以 SE 对文档的较真不是形式主义，而是把风险在上游便宜时就掐灭； 【⚠️ 2026 现状】文档形式在变（Wiki、协同看板），但【每阶段有可验收的产出物】这条铁律没变。

四、动手 Demo：阶段—工作—文档对照表

把六级阶段、各自动作与交付文档整理成一张对照表，当作本节的随身速查卡。

docs = [("需求定义", "需求规格说明书"),
        ("外部设计", "外部设计书"),
        ("内部设计", "内部设计书"),
        ("制作", "源代码 + 测试记录"),
        ("测试", "测试报告"),
        ("运用维护", "操作手册 + 维护记录")]
for stage, doc in docs:
    print(stage, "->", doc)

实跑输出：

--------------------------------------------------------------------
各个阶段的工作内容及文档
--------------------------------------------------------------------

瀑布每个阶段都有固定动作和固定【交付文档】——文档就是阶段的验收凭证:

  阶段         干什么               交付文档
  ------------------------------------------------------------
  需求定义     要解决什么问题       需求规格说明书
  外部设计     系统外观与接口       外部设计书(界面/接口)
  内部设计     系统内部怎么实现     内部设计书(模块/数据库)
  制作         写程序               程序源代码 + 单元测试记录
  测试         证明系统正确         测试计划 + 测试报告
  运用维护     上线并持续保养       操作手册 + 维护记录

    上游文档是下游的【施工图】: 需求书写不清, 设计就跑偏;
    设计书含糊, 编程就返工——文档不是形式, 是阶段之间交接的绳结。

六行表背下来，面试与实战都够用——它就是瀑布模型的【货物清单】。 注意每份文档都服务下游：测试报告服务运用，操作手册服务最终用户。

30 秒实验

  1. 默写六级阶段与各自的交付文档，再对照本节查漏。
  2. 举一个【需求书写含糊导致下游返工】的设想例子，指出哪一步就该拦住它。

常见误区

  1. 以为文档是行政负担——它是阶段验收凭证与下游施工图，砍文档等于拆护栏。
  2. 以为测试只是测试组的事——测试用例的评审从内部设计阶段就开始了。
自测三问（点开对答案） 1. 六个阶段各自的交付文档？ —— 需求规格书／外部设计书／内部设计书／源代码与测试记录／测试报告／操作手册。 2. 文档的本质作用？ —— 阶段验收凭证＋阶段间交接的绳结。 3. 下游爆发的问题根子常在哪？ —— 上游——需求书与设计书的含糊。

相关笔记