系统架构师考试自习–软件开发模型

一、软件开发模型总览

软件开发模型是软件生命周期全过程、活动、任务的结构化框架，用于：

– 规范阶段划分、输入输出、里程碑
– 控制质量、风险、进度、成本
– 适配需求稳定性、项目规模、合规要求

核心分类：

1. 传统线性模型：瀑布、V模型
2. 迭代/演化模型：原型、增量、迭代、螺旋
3. 现代敏捷/精益：Scrum、XP、Kanban
4. 工程化协同模型：DevOps、DevSecOps

二、传统线性过程模型

2.1 瀑布模型（Waterfall Model）

定义

严格顺序、线性、不可回溯、阶段驱动、文档驱动的经典生命周期模型，前一阶段完全结束并通过评审才能进入下一阶段。

标准流程（6阶段，严格单向）

1. 需求规格说明
– 输出：SRS（软件需求规格说明书）
– 活动：需求获取、分析、建模、确认、基线化
2. 概要设计（总体设计）
– 输出：总体设计文档、体系结构、模块划分、接口定义
3. 详细设计
– 输出：详细设计、数据结构、算法、模块逻辑
4. 编码与单元测试
– 输出：可执行单元、单元测试报告
5. 集成测试 & 系统测试
6. 验收、交付、维护

核心特征

– 阶段边界清晰，无迭代、无回头
– 强文档、强评审、强基线
– 问题发现越晚，修复成本指数上升

优点

– 管理简单、流程清晰、易于监控
– 适合小型、需求固定、变更极少项目
– 文档完整，便于审计、合规、交接

缺点

– 风险后置：测试阶段太晚，早期错误后期爆发
– 不支持需求变更，变更代价极高
– 用户参与少，最终产品与实际需求偏差大
– 周期长、反馈慢、灵活性极差

适用场景

– 需求极度稳定、明确、不可变
– 小型项目、嵌入式简单控制、教学演示、强合规政务/军工简单系统

典型风险

– 需求理解错误 → 后期大规模返工
– 后期才发现不可行、性能不达标

 

2.2 V模型（Verification & Validation Model）

定义

瀑布模型的测试对称扩展版，核心思想：测试与开发阶段一一对应，测试左移。
强调：每一层开发都对应一层测试，尽早设计测试用例。

完整V形结构（左右严格对称）

左侧（开发） ←→ 右侧（测试）

– 需求分析 ←→ 验收测试（用户场景、业务合规）
– 概要设计 ←→ 系统测试（功能、性能、接口、安全）
– 详细设计 ←→ 集成测试（模块间交互、接口）
– 编码实现 ←→ 单元测试（函数/类/模块内部逻辑）

关键细节

– 需求阶段就写验收/系统测试用例
– 设计阶段就写集成测试用例
– 编码前就明确单元测试标准
– 每个开发阶段结束，对应测试阶段立即启动

优点

– 测试活动提前、全面、可追溯
– 质量可控、验证充分
– 适合高可靠性、强安全、强验证领域

缺点

– 仍然是线性模型，不支持需求变更
– 对测试资源要求高、前期投入大

适用场景

– 嵌入式、车载、航空、医疗、工业控制、轨道交通
– 强安全、强合规、高可靠性系统

三、演化/迭代类模型（应对需求不明确）

3.1 快速原型模型（Rapid Prototype）

定义

先快速构建可演示、可交互原型，用于验证需求、消除歧义、获取用户反馈，再基于确认后的需求正式开发。

分类（核心考点）

1. 抛弃型原型（Throw-away Prototype）
– 只用于探索需求、验证界面/流程
– 验证完成后废弃，不进入正式产品
2. 演化型原型（Evolutionary Prototype）
– 原型逐步迭代、优化、扩展为最终产品
– 架构必须可扩展，否则后期技术债务极高

标准流程

1. 快速需求分析（核心需求）
2. 原型设计（界面、交互、核心流程）
3. 原型实现（快速开发工具：低代码/前端框架）
4. 用户评估、反馈、修改
5. 需求确认 → 正式开发

优点

– 极大降低需求风险、理解偏差
– 用户参与度高、满意度高
– 快速可视化，减少沟通成本

缺点

– 容易追求速度而忽略架构、性能、可维护性
– 进度、质量难以严格管控
– 用户可能误以为原型就是最终产品

适用场景

– 需求模糊、用户说不清需求
– 界面密集、交互复杂（APP、Web、管理系统）
– 新产品探索、需求验证类项目

3.2 增量模型（Incremental Model）

定义

将系统拆分为多个独立增量构件，每个增量按“设计→编码→测试→交付”独立完成，分批交付、逐步叠加功能。

核心思想

– 先交付核心、高价值、高风险增量
– 后续增量在已有系统上叠加
– 每一批都可独立运行、测试、交付

流程示例

增量1：登录、权限、基础数据
增量2：核心业务流程A
增量3：核心业务流程B
增量4：报表、统计、管理功能
…

与迭代模型的关键区别（必考）

– 增量：横向加功能（从少到多）
– 迭代：纵向求精（从粗到精、反复完善）

优点

– 早期即可交付可用系统，降低整体风险
– 可灵活分配人力、分阶段投入
– 变更只影响当前增量，不破坏整体

缺点

– 必须前期做好总体架构设计，否则增量叠加混乱
– 集成、回归测试成本高
– 若增量划分不合理，会出现依赖混乱

适用场景

– 大中型系统、工期紧张、需要先上线核心能力
– 需求可分层、可分批交付的项目

3.3 迭代模型（Iterative Model）

定义

多次循环：需求→设计→实现→测试→反馈，每一轮迭代都产出可运行、可测试版本，逐步完善功能与质量。

核心特征

– 每轮迭代都包含完整生命周期
– 每次都修正需求、优化设计、补充功能
– 风险分散、持续验证

流程（每轮迭代）

1. 迭代计划（范围、目标、验收标准）
2. 需求分析与细化
3. 设计与实现
4. 测试与修复
5. 评审与反馈 → 进入下一轮

优点

– 早期发现架构/需求问题，降低返工成本
– 支持需求逐步明确、灵活变更
– 持续交付可用版本，风险可控

缺点

– 若迭代目标模糊，易“原地打转、延期”
– 对团队能力、项目管理要求高

适用场景

– 大中型项目、需求逐步明确、中长期产品
– 架构需要持续验证的复杂系统

3.4 螺旋模型（Spiral Model）

定义

瀑布 + 原型 + 风险分析 结合，以风险驱动为核心，适合超大型、高风险、长周期项目。由 Barry Boehm 提出。

四象限（每一圈 = 一次迭代）

1. 制定目标与约束
– 需求、进度、成本、质量、资源
2. 风险分析与评估
– 识别风险、量化风险、制定规避/缓解方案
3. 开发与验证
– 原型、增量、实现、测试
4. 规划下一周期
– 复盘、调整范围、计划下一轮

核心特征

– 每轮都强制做风险分析
– 支持多轮原型、多轮验证
– 大型项目中风险控制最强

优点

– 风险控制能力极强
– 支持需求逐步明确、灵活调整
– 适合关键、高投入、高风险系统

缺点

– 流程复杂、管理成本极高
– 依赖专业风险分析师与资深架构师
– 小型项目完全不适用

适用场景

– 国家重大工程、航天、国防、金融核心交易系统
– 超大型、高风险、长周期、关键业务系统

四、现代主流：敏捷开发模型（Agile）

4.1 敏捷核心思想（敏捷宣言 2001）

– 个体与互动 高于 流程和工具
– 可用软件 高于 详尽文档
– 客户协作 高于 合同谈判
– 响应变化 高于 遵循计划

12条原则核心简化：

– 尽早、持续交付有价值软件
– 欢迎需求变更，即使在开发后期
– 频繁交付（几周到几个月）
– 业务与开发全程协作
– 面对面沟通
– 可工作软件是进度主要衡量
– 可持续开发、稳定节奏
– 技术卓越、好设计增强敏捷

4.2 Scrum（最主流敏捷框架）

角色（固定三角色）

1. Product Owner（PO 产品负责人）
– 负责产品愿景、需求排序、Backlog 管理
2. Scrum Master（SM 敏捷教练）
– 移除障碍、保障流程、保护团队
3. Development Team（开发团队）
– 跨职能、自组织、全栈能力（5~9人）

核心事件（固定仪式）

1. Sprint 迭代：1~4 周，固定时长
2. Sprint 计划会：确定本次目标与范围
3. 每日站会（15min）
– 昨天做了什么、今天做什么、有什么障碍
4. Sprint 评审会：演示可用软件、获取用户反馈
5. Sprint 回顾会：流程改进、经验复盘

核心工件

– Product Backlog：产品需求列表（动态维护）
– Sprint Backlog：迭代内任务
– 增量（Increment）：迭代结束可交付的可用软件

优点

– 快速响应变更、持续交付价值
– 团队自组织、效率高、沟通顺畅
– 用户反馈及时、风险低

缺点

– 文档少，不利于长期维护、合规审计
– 对团队成熟度、自律性要求高
– 大型项目规模化协调复杂

4.3 XP 极限编程（eXtreme Programming）

定义

工程实践最强的敏捷方法，面向高质量、快速变化、中小型团队。

核心实践（必背）

– 用户故事（User Story）
– 短迭代（1~2周）
– TDD 测试驱动开发（先写测试，再写代码）
– 重构（Refactoring）：不改变功能，优化结构
– 持续集成 CI：频繁构建、自动测试
– 结对编程（Pair Programming）
– 简单设计、集体代码所有制
– 现场客户（On-site Customer）

适用场景

– 需求变化极快、高质量要求、Web/互联网产品
– 小团队、高技能、高效率场景

4.4 Kanban 看板（精益敏捷）

核心思想

– 可视化工作流
– 限制在制品（WIP），避免过载
– 拉动式生产，完成一个再开始一个
– 持续度量、持续改进

适用场景

– 运维、支持、维护类团队
– 任务随机、优先级频繁变动
– 不想强改流程，只想优化效率

五、DevOps / DevSecOps 模型（现代工程标准）

定义

开发 + 测试 + 运维 + 安全 一体化，打破部门壁垒，通过自动化实现持续交付、快速反馈、快速修复。

核心流水线（CI/CD）

1. 持续集成 CI
– 代码提交 → 自动构建 → 单元测试 → 静态代码分析
2. 持续交付 CD
– 自动化测试（功能/接口/性能/安全）
– 自动化部署到测试/预发环境
3. 持续部署（可选）
– 自动发布到生产（灰度、蓝绿）
4. 监控 & 反馈
– 日志、指标、告警、用户反馈 → 驱动下一轮迭代

核心价值

– 发布频率高、部署风险低、回滚快
– 开发与运维目标一致（稳定+快速）

适用场景

– 互联网、云原生、SaaS、微服务、高频发布系统

六、全模型对比表

七、架构师选型决策规则

1. 需求固定 + 小项目 → 瀑布
2. 高可靠 + 强验证 → V模型
3. 需求不清 + 界面多 → 原型 + 迭代
4. 大系统 + 分批上线 → 增量
5. 复杂 + 需求渐变 → 迭代
6. 超大 + 高风险 + 长周期 → 螺旋
7. 互联网 + 快变 → Scrum/XP
8. 云原生 + 高频发布 → DevOps + 敏捷