1.1 软件危机与软件工程
先理解"为什么会有软件工程"——因为软件越写越大，乱写会翻车。
软件危机（表现要能列举）
- 进度和成本估算不准，项目经常超期超支；
- 用户对产品不满意，"做出来的不是想要的"；
- 质量不可靠、维护困难、文档缺失；
- 根本原因：软件规模变大而管理方式没跟上（软件是逻辑产品，写错了不会"断"给你看）。
软件工程的定义与三要素
- 把工程化的方法用到软件开发上：以系统、规范、可度量的方式开发、运行和维护软件。
- 三要素：方法（怎么做的技术）、工具（用什么做）、过程（按什么步骤做的）。
易错
- 软件工程不只是"写代码"——需求、设计、测试、维护都是它的地盘。
- 软件不是"物理产品生产的附属品"，它有自己的生命周期与交付形态。
课堂练习（2 题）
- 软件工程的三要素是什么？ 答：方法、工具、过程。
- 软件危机产生的主要原因是什么？ 答：软件规模与复杂度快速增长，而开发方式仍是"手工作坊式"，缺乏工程化的管理和方法。
1.2 软件生命周期：从想法到退役
每个阶段"做什么、产出什么"要能对上号。
| 阶段 | 做什么 | 主要产出 |
|---|---|---|
| 问题定义 / 可行性研究 | 确定"做不做、值不值得做" | 可行性研究报告 |
| 需求分析 | 确定"做什么" | 需求规格说明书、DFD、数据字典 |
| 设计 | 确定"怎么做"：总体设计 + 详细设计 | 设计说明书（架构、模块、接口、数据结构） |
| 编码 | 按设计写程序、单元测试 | 源代码 |
| 测试 | 发现并排除错误 | 测试报告 |
| 维护 | 交付后的修改与完善 | 新版软件、维护记录 |
记忆抓手
- 需求分析管"做什么"，设计管"怎么做"——这是全册出现频率最高的一句话。
- 测试"发现错误"，不是"证明程序正确"（这句在测试章节还会再考一次）。
课堂练习（2 题）
- "软件应该做什么"是在哪个阶段确定的？ 答：需求分析阶段。
- 软件生命周期中持续时间最长的阶段是哪个？ 答：维护阶段（通常占生命周期总成本的一半以上）。
1.3 过程模型：瀑布、原型、螺旋、敏捷
一张对比表覆盖大多数出题点。
| 模型 | 核心思想 | 优点 | 缺点 / 适用 |
|---|---|---|---|
| 瀑布模型 | 阶段严格串行，像瀑布一样一节节往下流 | 规范、文档全、易管理 | 不适应需求变更；需求明确的传统项目 |
| 原型模型 | 先快速做个样子（原型）给用户看，反复改 | 需求不明确时特别有效，减少"做完了才发现不对" | 原型易被误当成品；管理不当会失控 |
| 螺旋模型 | 瀑布 + 原型，一圈圈螺旋上升，每圈都做风险分析 | 适合大型、高风险项目 | 风险管理成本高，小项目不划算 |
| 增量 / 迭代 | 先交付部分功能，再逐步扩充 / 整体反复精化 | 尽早交付、尽早反馈 | 需要良好架构支撑 |
| 敏捷（Agile） | 小步快跑、拥抱变化：短迭代（如两周）、持续交付可用软件（Scrum、XP 等） | 响应变化快、用户参与度高 | 对团队自律要求高；文档相对少 |
两个常考的"独有特征"
- 带"风险分析"的是螺旋模型；带"快速原型反馈"的是原型模型。
- 强调"拥抱需求变化"的是敏捷方法。
课堂练习（3 题）
- 需求经常变化、用户说不清要什么，最不该选哪种模型？ 答：瀑布模型（串行推进，后期才见到成品，无法适应需求变更）。
- 哪个模型明确引入了"风险分析"？ 答：螺旋模型。
- 瀑布模型的各阶段顺序是什么？ 答：需求分析 → 设计 → 编码 → 测试 → 维护（前面还有可行性研究）。