7.3 软件开发模型 (7课时)
本课核心知识点整理
开发模型是“生命周期活动的组织方式”
生命周期告诉我们软件开发会经历计划、需求、设计、编码、测试、维护等活动；开发模型回答这些活动如何排列、是否迭代、什么时候交付、怎样处理风险和变化。
考试常给一个场景，让你判断适合或不适合哪种模型。判断入口通常是：需求是否明确、风险是否高、是否需要尽早交付、是否面向对象、客户是否持续参与。
一张总对比表
| 模型 | 核心关键词 | 适合 | 不适合/风险 |
|---|---|---|---|
| 瀑布模型 | 阶段严格、文档驱动、需求明确 | 需求稳定、过程规范、文档要求高 | 需求不清或频繁变化 |
| V 模型 | 开发活动与测试活动对应，测试提前设计 | 重视验证确认、测试计划前移 | 仍保留线性模型对变化不敏感的问题 |
| 原型模型 | 快速原型、用户反馈、澄清需求 | 需求不明确、界面/交互需要沟通 | 原型被误当成最终系统，范围易失控 |
| 螺旋模型 | 迭代 + 风险分析 | 大型、复杂、高风险项目 | 成本高，需要风险分析能力 |
| 增量模型 | 核心增量先交付，逐步扩展 | 希望尽早交付可用版本 | 增量划分和模块划分难 |
| 喷泉模型 | 面向对象、迭代、无间隙、阶段重叠 | 面向对象开发 | 阶段边界不清，管理要求高 |
| 统一过程 UP | 用例驱动、架构为中心、迭代增量 | 面向对象、中大型项目 | 概念体系较多，实施成本较高 |
| 敏捷方法 | 小步快跑、客户协作、响应变化 | 小团队、需求变化快、持续反馈 | 不适合客户无法参与或高度强文档管控场景 |
技术迭代的主线
| 旧问题 | 新模型/方法怎么补 |
|---|---|
| 瀑布模型要求需求明确，但现实需求常有渐进明细性 | 原型模型通过可见原型帮助用户澄清需求 |
| 原型能澄清需求，但大型项目还有技术、成本、进度等风险 | 螺旋模型把风险分析引入每一轮迭代 |
| 一次性交付太晚，用户迟迟用不到系统 | 增量模型先交付核心功能，再逐步扩展 |
| 结构化方法对复杂对象关系表达不自然 | 喷泉模型和 UP 结合面向对象思想 |
| 文档和计划无法完全预测变化 | 敏捷方法用短周期交付和客户协作响应变化 |
做题判断树
text
需求明确稳定？ -> 优先考虑瀑布/V
需求不明确？ -> 优先考虑原型/演化
风险高、规模大、复杂？ -> 优先考虑螺旋
要分批交付可用版本？ -> 优先考虑增量
面向对象、阶段可重叠？ -> 优先考虑喷泉
用例驱动、架构为中心？ -> 优先考虑 UP
小团队、变化快、客户持续参与？ -> 优先考虑敏捷例题
特别强调风险分析，适合大型复杂高风险项目的软件开发模型是：
若题干明确说“需求不明确、业务流程可能变化”，最不适宜优先采用的是：
自查要点
- 开发模型和生命周期是什么关系？
- 需求不明确时为什么不适合瀑布模型？
- 原型、螺旋、增量三者分别解决什么痛点？
- 喷泉模型和 UP 为什么常与面向对象联系？
- 敏捷方法为什么说是“小步快跑”？