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

最经典的开发规范是瀑布模型：需求→设计→制作→测试→运用逐级而下，上一级收尾下一级才开工——顺序不可倒置。

📝 本节和前面几节的关系

SE 怎么把几十人的工程管出秩序？靠成文的开发过程规范。本节看教科书级的瀑布模型。

一、瀑布模型：逐级落下的流程

阶段顺序：需求定义 → 外部设计 → 内部设计 → 制作 → 测试 → 运用（维护）； 像瀑布逐级落下：上一阶段没验收，下一阶段绝不开工； 理由是返工代价：上游改一句话，下游全部跟着翻——越晚发现，修正成本越高。

二、规范的价值与代价

价值：阶段有出口条件、产出可验收、责任可追溯——几十人协作出秩序； 代价：节奏僵硬——客户到后期才看到真系统，改需求如同推倒重来； 【⚠️ 2026 现状】后来出现的迭代式与敏捷开发，用【小步快跑、每轮可交付】化解僵硬——但【阶段有产出、质量有验收】的内核与瀑布一脉相承。

三、还有别的过程模型

原型法：先做个演示版让客户提意见，再正式开发——需求易变的场合常用； 螺旋模型：每轮【计划→风险分析→开发→评审】转一圈，逐圈扩大——大项目的风险管控思路； 学瀑布不是学教条，是学【把大工程切成可控阶段】的方法论底座。

四、动手 Demo：瀑布的六级与放行检查

把瀑布模型画成逐级缩进的流程，再跑一遍【完成度 100% 才放行】的检查逻辑。

flow = ["需求定义", "外部设计", "内部设计",
        "制作", "测试", "运用维护"]
progress = [100, 100, 100, 60, 0, 0]
for s, pct in zip(flow, progress):
    gate = "放行" if pct == 100 else "进行中"
    print(s, pct, gate)

实跑输出：

--------------------------------------------------------------------
系统开发过程的规范
--------------------------------------------------------------------

开发过程最经典的规范是【瀑布模型】: 阶段像瀑布逐级落下,
上一级没收尾, 下一级绝不开工——倒着返工的代价最大, 所以顺序铁打:

        需求定义
              v
              外部设计
                    v
                    内部设计
                          v
                          制作
                                v
                                测试
                                      v
                                      运用维护

    [执行检查: 每级完成度到 100% 才放行下一级]
        需求定义   完成度 100% 已放行
        外部设计   完成度 100% 已放行
        内部设计   完成度 100% 已放行
        制作     完成度  60% 进行中
        测试     完成度   0% 进行中
        运用维护   完成度   0% 进行中

【⚠️ 2026 现状】瀑布之后又长出迭代式、敏捷开发(小步快跑、每两周可交付)
——但【先想清楚再动手、阶段有产出物】的思想内核没变, 学瀑布仍是入门正道。

制作环节 60%——它和它后面全部【进行中】，前面的已放行：瀑布的纪律一眼可见。 把 progress 改成迭代式再想想：每一轮小瀑布各自 100%，大系统分多次交付。

30 秒实验

  1. 画一遍瀑布六级流程，并给每级配一个【不能跳级】的理由。
  2. 对比瀑布与敏捷：各找一个最适合的场景。

常见误区

  1. 以为瀑布过时了就不必学——它是所有过程模型的方法论底座，敏捷也踩在它肩上。
  2. 以为规范是束缚——没有规范，几十人的项目连【谁负责什么】都说不清。
自测三问（点开对答案） 1. 瀑布模型的六级顺序？ —— 需求定义→外部设计→内部设计→制作→测试→运用维护。 2. 【上一级收尾才开工】防的是什么？ —— 越晚越贵的返工——上游错一句话，下游全部翻工。 3. 瀑布的代价与补救？ —— 节奏僵硬、后期才见真系统；补救是迭代／敏捷的小步交付。

相关笔记