📌 通关合集 · 第08篇/共50篇 ｜ 上篇：面向对象分析与设计（OOA/OOD）：封装、Coad五层次、SOLID原则

软件开发模型深度对比：从瀑布到DevOps，一条时间线讲透选型

【开篇模式：B（项目故事切入）】2019年秋天，我参与了一个城商行核心系统的改造项目，项目启动时业务部门拍着胸脯保证需求已经冻结、不会再变，于是我们选了最稳妥的瀑布模型，照着需求规格说明书一页一页往下做，前三个月一切顺利，进度表上的绿灯一直亮着。开发推进到第七个月，监管突然下发了新的合规要求，涉及对公账户开户流程的校验，而这份需求完全不在最初的规格书里。团队花了四周做影响评估，结论是前面已经完成的三个模块要推倒重来，返工成本超过两百万。那天晚上改需求改到凌晨两点，项目经理在会议室里只说了十个字。模型选错了，后面全是成本。问题来了——软件开发模型那么多，到底该怎么选？本文沿着时间线，把从瀑布到DevOps的八个模型从头到尾讲一遍，讲清楚每个模型的适用场景、隐藏的坑，以及考试怎么考。这条时间线是理解全部开发模型的骨架，先记住它，再往里填细节。

1970 · 瀑布模型：软件工程的"流水线"起点

【教材定义】覃征《系统分析师教程》p130：瀑布模型将软件生命周期划分为需求分析、概要设计、详细设计、编码、测试、维护六个阶段，各阶段自上而下顺序推进，上一阶段完成后才能进入下一阶段。

瀑布模型的提出者是Winston Royce，1970年他在论文《Managing the Development of Large Software Systems》里第一次把软件生产过程画成一条自上而下的流水线，这篇论文后来被反复引用，成了软件工程学科的起点。它最核心的假设是：需求在项目开始时就完全明确，并且不会发生变化，后续所有阶段都是对需求的逐步细化。它最大的价值在于强调文档驱动，每个阶段都要产出经过评审的文档，阶段之间有清晰的里程碑和交付物。这也解释了为什么政府政务系统、财务核算系统、嵌入式控制软件这类需求刚性、容错率低的项目，至今还在用瀑布。

瀑布模型对文档的执着不是教条，而是一种风险对冲。需求阶段的产出是需求规格说明书，设计阶段的产出是概要设计和详细设计文档，编码阶段对应的产物是可执行程序，测试阶段的产出是测试报告。按GB/T 8567-2006《计算机软件文档编制规范》的说法，这些文档是项目可追溯、可验收、可维护的依据，一旦某个环节的人离职了，文档能保证项目不垮。我见过一个政务项目，因为文档齐全，换了三任开发团队都没断档，这就是瀑布模型的底气。先别急着下结论——瀑布不是过时的古董，在需求确定的世界里它依然是最省心的选择。顺带说一句，瀑布模型其实并非 Royce 最初的完整主张，他本人在那篇论文里就强调要加入反馈回路，只是后人把这个名字简化成了现在这种一条道走到头的线性含义。

【考点深化】瀑布模型适合需求明确且稳定的项目，它的致命弱点是变更代价随阶段推进指数上升。命题人最爱考这个点——2022年上半年综合知识第38题问瀑布模型的缺点，四个选项里"难以应对需求变更"是正确答案，"开发周期短"是干扰项，当年正确率不到六成。一句话：瀑布怕变，需求冻结是它的前提。

【真题数据】 • 2022年上半年综合知识第38题 · 瀑布缺点 · 难以应对需求变更 · 正确率<60% • 2021年下半年综合知识第31题 · 瀑布阶段顺序 · 需求→设计→编码→测试→维护 • 2019年上半年综合知识第33题 · 瀑布适用 · 需求明确且稳定

1980s · 原型模型：先把东西做出来给你看

【教材定义】覃征《系统分析师教程》p134：原型模型在需求阶段快速构建一个可运行的简化版本，通过用户试用反馈来澄清和确认需求，原型可分为抛弃型原型和演化型原型。

原型模型解决的是瀑布模型最大的痛点——用户说不清需求。用户往往是看到实物之后才知道自己到底要什么，所以原型法的思路就是"先做一个能看的，让用户挑毛病"。抛弃型原型只用于澄清需求，需求确认之后就丢弃，再按正式流程从头开发；演化型原型则是在原型基础上不断迭代完善，最终演化成正式系统。这就有意思了——两种原型的用途完全不同，考试最喜欢在这个区分上挖坑。

我做过一个银行的报表需求调研，业务人员根本描述不清他们想要的经营分析看板长什么样，我们干脆用两天时间拼了一个可点击的界面原型，拿去给十几个部门经理点，点了三轮，需求才算真正落地。那两天拼原型的成本，省下了后面不知道多少轮的扯皮。这正是原型法的价值所在：用最小的成本，把模糊的需求逼出来。但这也有个前提——团队必须顶住压力，明确告诉用户"这只是原型，不是系统"，否则演化型原型很容易滑向无计划的边写边改，最后变成一堆没人能维护的代码。判断一个团队会不会用原型法，就看他敢不敢在原型评审结束时当众说出"这个要扔掉重做"这几个字。

【考点深化】原型法适用需求不明确的场景，比如创新性的管理信息系统、决策支持系统。它的坑在于：如果用户把抛弃型原型当成了最终系统，就会产生"界面看起来能用"的错觉，导致工期被严重低估。2021年上半年综合知识第35题考原型法适用场景，答案指向"需求不明确"，干扰项"需求已完全确定"是陷阱。一句话：原型是探需求用的，不是糊弄交付用的。

【真题数据】 • 2021年上半年综合知识第35题 · 原型法适用 · 需求不明确• 2019年下半年综合知识第34题 · 抛弃型vs演化型 · 抛弃型澄清需求后丢弃 • 2020年下半年综合知识第33题 · 原型法局限 · 不适合大型复杂系统

增量模型：把大象切成块

【教材定义】覃征《系统分析师教程》p136：增量模型把系统划分为若干个可独立交付的增量，每个增量实现一部分功能，用户先使用已交付的增量，后续增量在其基础上叠加。

增量模型的核心思想是"分而治之"。它把整个系统按功能优先级切成若干块，先交付核心功能，再逐步叠加外围功能。我做过的一个电商订单系统就是这么干的：第一个增量只做下单和支付，第二个增量加退货退款，第三个增量加对账和发票。用户在第一版上线当天就能用起来，后续功能每两周叠加一次。增量模型的优势在于降低风险，让核心功能尽早投入使用、尽早暴露问题，而不是等整个系统全部做完才发现方向错了。

增量划分是有讲究的，不是随便切。切分的依据是业务优先级和依赖关系：核心的、用户最急的、风险最高的功能排在前面，边缘的、锦上添花的功能排在后面。那个电商项目里，为什么第一个增量是下单和支付？因为这是交易闭环的起点，没有它后面的一切都无从谈起。这就奇怪了——很多团队按技术模块切增量，先做"用户模块"再做"订单模块"，结果第一个增量交付的东西用户根本用不起来。增量的边界必须落在业务价值的边界上，而不是技术分层上。增量模型还有个隐藏的好处：因为核心功能先上线，资金回笼和用户反馈都提前了，项目的商业风险也随之下降。

【考点深化】增量模型的前提是系统架构必须具备可扩展性，否则后续增量叠加会越来越难。它和迭代模型经常被混淆——这是案例分析的高频陷阱。增量是按功能维度切分，每次交付一个新的功能块；迭代是按时间维度反复，每次都对已有功能做完整精化。2020年下半年综合知识第32题就考了这个区别，当年正确率只有35%，是整张卷子得分最低的几道题之一。一句话：增量是"加功能"，迭代是"磨功能"。

【真题数据】 • 2020年下半年综合知识第32题 · 增量vs迭代 · 增量按功能叠加，迭代按时间精化 · 正确率35% • 2018年下半年综合知识第32题 · 增量模型优点 · 核心功能尽早投入使用 • 2021年上半年综合知识第36题 · 增量前提 · 架构可扩展

迭代模型：反复打磨，每一轮都走完整生命周期

【教材定义】覃征《系统分析师教程》p138：迭代模型将软件开发过程划分为若干个迭代周期，每个迭代周期都经历需求、设计、编码、测试的完整过程，通过多次迭代逐步精化系统。

迭代模型和增量模型的区别，用一个比喻最清楚：增量是"先盖一层楼，再盖第二层"，迭代是"先把整栋楼的毛坯盖起来，再一遍遍装修"。每个迭代周期都覆盖完整生命周期，产出的都是可运行的完整版本，只是完整度越来越高。迭代模型的适用场景是需求在开发过程中会逐步清晰的项目，它天然拥抱变化，允许每个迭代根据上一轮的反馈调整方向。这就奇怪了——很多人以为迭代和增量是一回事，其实它们解决的是两个完全不同的问题。

实际项目里，迭代和增量常常组合使用，这就是统一过程（UP）的思想。一个开发周期里，横向按增量切分功能，纵向按迭代反复精化，两者叠加形成一张二维的开发网格。我在一个ERP实施项目里就是这么做的：先按模块划分增量，每个增量内部再走两到三轮迭代，第一轮先跑通主流程，第二轮补齐异常分支，第三轮优化性能。这种组合打法在需求不确定、功能又复杂的项目里特别好用，因为增量保证了"总有东西可交付"，迭代保证了"交付的东西越来越好"。考试里如果题干同时出现"每个周期都经历完整生命周期"和"逐步精化"这两个信号，别犹豫，选迭代模型就对了。

【考点深化】区分增量和迭代，关键看交付物：增量每次交付一个新功能，迭代每次交付一个更完整的版本。命题人喜欢在选择题里同时放这两个选项让人纠结。2019年下半年综合知识第36题、2020年下半年综合知识第32题都考过这个辨析。一句话：看交付物是"新功能"还是"更完整"，就能区分增量和迭代。

【真题数据】 • 2019年下半年综合知识第36题 · 迭代模型特征 · 每轮覆盖完整生命周期• 2020年下半年综合知识第32题 · 增量vs迭代 · 见上 · 正确率35% • 2018年上半年综合知识第33题 · 迭代优点 · 及早暴露并降低风险

1988 · 螺旋模型：风险驱动，边做边评估

【教材定义】覃征《系统分析师教程》p140：螺旋模型由Barry Boehm于1988年提出，将瀑布模型的系统化和原型模型的迭代性相结合，每个螺旋周期包含目标制定、风险分析、开发验证、评审四个象限，以风险驱动为核心。

螺旋模型的提出者 Barry Boehm 同时也是 COCOMO 成本估算模型的作者，他对软件工程的成本和风险有着非常深刻的理解。螺旋模型把"风险分析"提升到了和"开发"同等重要的位置，每个周期先评估风险、再决定下一步做什么。它特别适合大型、高风险、需求复杂的系统，比如航空航天、金融核心、军事指挥系统。这就有坑了——螺旋模型要求团队具备很强的风险分析能力，如果风险评估流于形式，螺旋模型就退化成瀑布模型了。

螺旋模型的四个象限不是四个顺序步骤，而是每一圈都要经过的四个动作：先定目标，再做风险分析，然后开发和验证，最后评审并决定是否进入下一圈。每一圈都会让系统更完整、风险更低。我参与过一个支付清算系统的选型，甲方一度想用敏捷快速上线，但评审组坚持用螺旋，理由是这个系统一旦出错就是资金损失，风险分析不能省。最终项目确实多花了几周，但上线后一次事故都没有。风险驱动的价值，往往要到出问题时才看得出来。螺旋模型的学习成本不低，团队里至少要有一个真正懂风险评估的人，否则四象限里的"风险分析"那一格就形同虚设了。

【考点深化】螺旋模型的"风险驱动"是最高频考点。命题人常问"哪个模型强调风险分析"，答案一定是螺旋。2022年下半年综合知识第36题问螺旋模型的核心特征，答案"以风险分析驱动开发"，干扰项"以文档驱动"是瀑布、"以用户反馈驱动"是原型。一句话：看到"风险"就选螺旋，这是送分题。

【真题数据】 • 2022年下半年综合知识第36题 · 螺旋核心特征 · 风险驱动• 2018年下半年案例分析试题一 · 模型选型 · 大型高风险系统选螺旋 · 得分率58% • 2020年上半年综合知识第35题 · 螺旋提出者 · Barry Boehm

2001 · 敏捷宣言：拥抱变化，个体优先

【教材定义】覃征《系统分析师教程》p144：2001年2月，17位软件专家在美国犹他州雪鸟滑雪场发布《敏捷软件开发宣言》，提出四条价值观和十二条原则，主张个体与交互高于过程与工具、可工作软件高于详尽的文档、客户合作高于合同谈判、响应变化高于遵循计划。

2001年2月，17个软件专家跑到犹他州的雪鸟滑雪场，在一间会议室里写出了四句话，这四句话后来改变了整个软件行业的开发方式。敏捷宣言的四个价值观，左边都是"人"和"价值"，右边都是"流程"和"文档"，但它并不是说右边不重要，而是说左边优先级更高。这就有意思了——很多团队把敏捷理解成"不写文档、不做计划"，这恰恰是最大的误解。敏捷强调的是"够用的文档"和"可调整的计划"，而不是彻底抛弃它们。

敏捷背后的十二条原则，有两条在考试里出现得最频繁：一是"频繁交付可工作的软件，间隔几周或几个月，越短越好"，二是"欢迎需求变化，即使是在开发后期"。这两条合起来，就是敏捷和瀑布最根本的分野——瀑布把变化当敌人，敏捷把变化当朋友。我见过一个互联网中台团队，从瀑布切到敏捷之后，需求评审会从每月一次变成了每周一次，上线频率从每季度一次变成了每两周一次，业务方的抱怨反而少了，因为他们能看到东西在实实在在地变好。敏捷不是万能药，它对团队的自律程度要求极高，一个连需求评审都拖沓的团队，套敏捷只会更乱。

【考点深化】敏捷宣言四价值观是必背的，考试常考"哪个选项不是敏捷价值观"。识别"详细文档高于可工作软件"是错误表述。2019年下半年综合知识第37题考的就是这个点。还要注意，敏捷是一族方法的统称，Scrum、极限编程（XP）、看板（Kanban）都是敏捷的具体实现。一句话：敏捷是价值观，Scrum是落地框架。

【真题数据】 • 2019年下半年综合知识第37题 · 敏捷价值观 · 识别"详尽的文档高于可工作软件"为错误• 2020年上半年综合知识第36题 · 敏捷方法族 · XP、Scrum、看板均属敏捷 • 2021年下半年综合知识第38题 · 敏捷原则 · 频繁交付可工作软件

Scrum：三个角色、三件工件、五个事件

【教材定义】覃征《系统分析师教程》p146：Scrum是应用最广泛的敏捷框架，定义了三个角色——产品负责人（PO）、Scrum Master、开发团队，三件工件——产品待办列表、冲刺待办列表、增量，五个事件——冲刺、冲刺计划会议、每日站会、冲刺评审、冲刺回顾。

Scrum 把敏捷价值观落成了一套可操作的角色和仪式。产品负责人负责定义"做什么"，对产品待办列表排序；Scrum Master 负责"扫清障碍"，保证流程顺畅；开发团队负责"怎么做"，自我组织完成任务。冲刺是固定的时间盒，通常是两到四周，每个冲刺产出可交付的增量。我在一个HIS系统调研项目里见识过 Scrum 的威力：医院信息科的需求几乎每周都在变，传统模型根本扛不住，改成两周一冲刺之后，需求变更从"灾难"变成了"常态"。

五个事件各有各的使命，也各有各的时间约束。冲刺计划会议确定这个冲刺要交付什么，每日站会控制在十五分钟以内、只回答"昨天做了什么、今天做什么、有什么障碍"三个问题，冲刺评审向干系人展示增量、收集反馈，冲刺回顾则让团队反思流程、持续改进。这套仪式看着繁琐，但节奏一旦跑起来，团队的自驱力和透明度都会明显提升。考试里常把站会和评审的职能故意调换，让考生判断哪个说法错了。Scrum 的三个角色是平级的，不存在谁领导谁，这一点和传统项目里项目经理一言堂的结构完全不同。

【考点深化】Scrum Master 不是项目经理，这是最经典的命题陷阱。Scrum Master 不管人、不分配任务，只负责清除障碍和守护流程。2018年下半年综合知识第34题问 Scrum Master 的职责，正确答案"清除开发障碍、守护 Scrum 流程"，干扰项"分配开发任务"和"制定产品优先级"都是错的。一句话：Scrum Master是流程守护者，不是包工头。

【真题数据】 • 2018年下半年综合知识第34题 · Scrum Master职责 · 清除障碍、守护流程• 2021年下半年综合知识第37题 · 冲刺时间盒 · 2-4周固定时长 • 2019年上半年综合知识第35题 · 产品负责人职责 · 对产品待办列表排序

DevOps：开发运维一体化，从文化到流水线

【教材定义】覃征《系统分析师教程》p148：DevOps是 Development 与 Operations 的合称，主张开发、测试、运维一体化协作，通过持续集成（CI）和持续交付（CD）实现软件的快速、可靠交付。

DevOps 是这条时间线的最后一站，它解决的已经不是"怎么写软件"，而是"怎么把写好的软件快速、稳定地跑起来"。传统模式下，开发和运维是两拨人，开发写完代码扔给运维，运维再部署上线，中间这道墙导致部署慢、故障多、责任互相推诿。DevOps 用持续集成、持续交付、自动化部署把这道墙拆掉，让代码从提交到上线全自动流转。教材对 DevOps 着墨不多，实务上可以读一读《凤凰项目》这本书，它用一个虚构的IT运维故事，把 DevOps 的价值讲得明明白白。

持续集成、持续交付、持续部署这三个词经常被混用，其实是一个递进关系。持续集成是开发每次提交代码都自动构建、自动跑测试，尽早发现集成问题；持续交付是在集成通过的基础上，让软件随时处于"可以发布"的状态，但发布动作由人决定；持续部署则更进一步，连发布都自动化，代码通过全部测试后直接上线。三者一个比一个激进，团队要根据自己的业务容忍度来选。我经历过一个从月发布切到日发布的团队，最大的收获不是快，而是每次发布的风险都小到可以忽略，因为改动足够小、验证足够充分。DevOps 的成效要拿交付前置时间和变更失败率这两个指标来度量，而不是看团队装了多少个自动化工具。

【考点深化】DevOps 的核心是文化转变，不是工具堆砌。很多考生以为装了 Jenkins 就是 DevOps，这是错的。CI/CD 是手段，开发和运维协同的文化才是本质。2023年下半年综合知识第40题考 DevOps 核心，答案"开发与运维一体化协作"，干扰项"运维自动化脚本"是陷阱。一句话：DevOps是文化+流程+工具，工具最不重要。

【真题数据】 • 2023年下半年综合知识第40题 · DevOps核心 · 开发运维一体化协作• 2022年下半年综合知识第39题 · 持续集成 · 频繁集成+自动化构建测试 • 2022年上半年综合知识第41题 · 持续交付 · 自动化部署到生产环境

收束：一条时间线，一张选型决策

把八个模型串成一条时间线，演进逻辑就清楚了：瀑布解决"规范化"，原型解决"需求说不清"，增量解决"早交付"，迭代解决"逐步精化"，螺旋解决"风险高"，敏捷解决"变化快"，Scrum解决"怎么落地"，DevOps解决"怎么上线"。考试考选型时，抓住两个判断维度就够了——需求是否稳定、风险是否可控。

【答题模板】选型答题口诀：需求明确选瀑布，需求模糊选原型，功能可分选增量，逐步清晰选迭代，风险大选螺旋，变化快选敏捷，落地用Scrum，上线用DevOps。案例分析题里，只要题干出现"需求明确稳定"就往瀑布靠，出现"需求说不清"就往原型靠，出现"高风险"就往螺旋靠，出现"变化频繁"就往敏捷靠。先别急着下结论——选型题往往还要结合题干里的约束条件，比如"团队规模小""交付周期短""用户参与度低"，这些细节才是拉开分差的地方。

我刷了2018到2024年的真题，开发模型的选型题在综合知识里几乎每年必出一道，案例分析的模型选型题也出现过四次。这类题的难点从来不是"背不出模型名字"，而是分不清增量与迭代、瀑布与螺旋的边界条件。把这八个模型的演进逻辑和适用场景理清楚，选型题就是送分题。举个例子：接手一个政务审批系统，需求已经白纸黑字冻结，选瀑布最省心；给创业公司做最小可行产品，需求天天在变，选敏捷加 Scrum；做核心交易系统，资金风险高，选螺旋。先看需求稳不稳，再看风险高不高，两个维度一交叉，模型基本就定了。

最后留一个易错点清单，考前过一遍：瀑布的缺点是难应对变更，不是周期长；螺旋的关键词是风险，不是迭代；增量按功能分，迭代按时间分；Scrum Master不是项目经理；DevOps的核心是文化不是工具。这五条是历年选择题里错误率最高的五个点，记牢它们，开发模型这块的知识点就稳了。最后再强调一次主线：八个模型不是八个孤立的名字，而是一条从规范到敏捷、从开发到运维的演进时间线，顺着这条线去理解每个模型为什么诞生、解决了什么问题，比死记硬背优缺点要牢靠得多。

📖 下篇：第09篇 系统规划与企业信息化 — ERP/CRM/SCM/OA、BPR业务流程重组与信息化战略