软件工程专题 · 13 分头号大坑
软考·软件设计师 ｜ 上午 13 分 + 下午 DFD 案例题必答 ｜ 复习优先级 = 分值 × 未掌握度 = 最高
⚠️ 为什么先啃这块：上午卷面 13 分（最高），下午第 1 题数据流图 DFD 是必答送分题。软工不学透，上午丢分 + 下午送分题也丢。本专题 = 开发模型 / 需求工具 / 内聚耦合 / McCabe / 测试 / 维护 / 质量。
① 开发模型（12 分）
软件开发"怎么走流程"，就是开发模型。考"给个场景/特点，问是哪个模型"。
| 模型 | 核心思想 | 特点 / 题眼 | 缺点 |
|---|
| 瀑布模型 |
阶段像瀑布一样**线性顺序**：需求→设计→编码→测试→维护 |
文档驱动，阶段间有严格评审；适合需求明确、稳定的项目 |
缺乏灵活性，难以应对需求变更（最常考缺点） |
| 原型模型 |
先快速做个"样品"给用户看，反复修改 |
适合需求不明确；帮助澄清需求 |
原型可能被误当成品 |
| 螺旋模型 |
原型 + 瀑布，一圈圈螺旋上升 |
引入"风险分析"（最大特色）；适合大型、高风险项目 |
风险分析成本高 |
| 增量模型 |
分批交付，每次做一个"增量"（部分功能） |
先给核心功能，逐步完善；用户能早用上 |
需良好的架构规划 |
| 喷泉模型 |
面向对象开发，各阶段无缝、迭代、重叠 |
“喷泉”比喻阶段像水一样上下翻滚、无间隙 |
管理复杂 |
| 敏捷（Agile） |
短周期迭代、快速交付可工作软件 |
快速迭代交付、拥抱变化、重人轻文档 |
不重文档，大团队难协调 |
| 统一过程 RUP |
4 阶段：初始→精化→构建→转换；用例驱动、以架构为中心、迭代增量 |
AUP（敏捷统一过程）= 在大型上连续、小型上迭代 |
— |
| V 模型 |
开发与测试一一对应（见测试章节） |
强调测试贯穿始终 |
— |
🧠 题眼秒杀：
看到"缺乏灵活性 / 需求变更难" → 瀑布
看到"风险分析" → 螺旋（唯一带风险分析的）
看到"快速迭代 / 短周期 / 可工作软件" → 敏捷
看到"需求不明确 / 先做样品" → 原型
看到"面向对象 / 无缝 / 迭代重叠" → 喷泉
看到"分批 / 增量交付" → 增量
📊 模型长啥样（图形记忆）
需求分析 ↓
概要设计 ↓
详细设计 ↓
编码实现 ↓
测试维护 ↓
瀑布模型：一级级往下，不能回头（缺灵活性）
螺旋模型：原型+瀑布，每圈做风险分析
喷泉模型：面向对象，阶段无缝迭代
② 需求分析工具（11 分）
需求分析阶段要产出：数据流图 DFD、数据字典、E-R 图、状态转换图、用例图。不包括：软件体系结构图（那是设计阶段）。
DFD 数据流图（下午第 1 题必考）
DFD 四种元素（必背，画图/补图全靠它）：
| 元素 | 图形 | 说明 |
|---|
| 外部实体 | 矩形 □ | 系统外的人/系统，如"用户""银行" |
| 加工（处理） | 圆角矩形 / 圆 ○ | 对数据做处理，如"计算成绩" |
| 数据存储 | 双横线 / 开口矩形 | 数据的存放处，如"学生表" |
| 数据流 | 带箭头 → | 数据的流向，标名称 |
⚠️ DFD 没有"控制流"！控制流是程序流程图的概念。（历年高频错点）
DFD 的"平衡"原则（下午题判分点）
父图和子图必须平衡：
• 父图中某个加工的输入/输出数据流，必须和它分解出的子图的边界输入/输出数据流一致（数量、方向、名称）。
• 子图内部加工之间新增数据流，不体现在父图。
📐 DFD 四要素长什么样（画图必认）
📐 DFD 示例（带进出数据流）
外部实体「用户」→ 加工「计算成绩」→ 数据存储「成绩表」，箭头是数据流（不是控制流）
数据字典 DD
数据字典 = 对 DFD 中每个数据流、数据项、数据存储、加工的精确定义（名字、别名、类型、来源去向）。DFD 画骨架，数据字典填血肉
其它需求工具
| 工具 | 面向 | 用途 |
|---|
| E-R 图 | 数据 | 描述实体-联系，数据库设计 |
| 状态转换图 | 行为 | 描述系统状态变化 |
| 用例图 | 功能/用户 | OO 需求，描述参与者与系统交互 |
③ 模块设计：内聚 & 耦合（3+4 分）
耦合（Coupling）——越低越好
耦合 = 模块之间联系的紧密程度。设计目标是高内聚、低耦合。从低到高：
| 排序 | 类型 | 说明 |
|---|
| 最低✅ | 非直接耦合 | 模块间无直接联系 |
| ↓ | 数据耦合 | 通过简单数据参数交换（如传 int） |
| ↓ | 标记耦合 | 通过参数表传递"数据结构/记录" |
| ↓ | 控制耦合 | 传递"控制信息"（开关、标志）控制对方 |
| ↓ | 外部耦合 | 模块都访问同一外部设备/格式 |
| ↓ | 公共耦合 | 多个模块共享公共数据环境（全局变量/公共区） |
| 最高❌ | 内容耦合 | 一个模块直接访问另一个模块内部数据/代码 |
🧠 题眼："通过外部变量交换输入输出" = 公共耦合（共享公共环境）；"传简单数据参数" = 数据耦合；"传记录/结构" = 标记耦合；"传开关标志" = 控制耦合。
口诀：非→数→标→控→外→公→内（越好越前）
内聚（Cohesion）——越高越好
内聚 = 模块内部各元素结合的紧密程度。从高到低：
| 排序 | 类型 | 说明 |
|---|
| 最高✅ | 功能内聚 | 完成一个单一功能，各部分缺一不可 |
| ↓ | 顺序内聚 | 处理元素相关且必须顺序执行 |
| ↓ | 通信内聚 | 所有处理元素在同一数据结构上操作 |
| ↓ | 过程内聚 | 处理元素相关，必须按特定次序执行 |
| ↓ | 时间内聚 | 任务必须在同一时间间隔内执行（如初始化） |
| ↓ | 逻辑内聚 | 完成逻辑上相关的一组任务 |
| 最低❌ | 偶然内聚 | 一组毫无关系/松散关系的任务 |
🧠 题眼："所有处理元素都在同一个数据结构上操作" = 通信内聚；"必须按特定次序执行" = 过程内聚；"同一时间间隔" = 时间内聚。
口诀：功→顺→通→过→时→逻→偶（前越高越紧）
📊 耦合 & 内聚 梯度一览
设计目标 = 高内聚（往上）+ 低耦合（往上）：让模块内部抱团、模块之间少牵扯
⚠️ 高频混淆：顺序内聚 vs 过程内聚（教材 319 页原文）
| 顺序内聚 | 过程内聚 |
|---|
| 依赖类型 | 数据依赖（前一输出 = 后一输入） | 流程依赖（只是先后次序） |
| 模块内容 | 密切相关于同一功能 | 完成多个任务 |
| 类比 | 流水线（原料层层加工） | 仪式流程（一步步走，不传东西） |
| 例子 | 读数据→求和→求平均（数据顺着流） | 清屏→打印横幅→检查授权→启动（无数据流） |
| 题眼 | "前一处理的输出是后一处理的输入" | "必须按指定过程/特定次序执行" |
一句话：传数据 = 顺序；不传数据、只讲次序 = 过程。
模块设计原则
• 目标：高内聚、低耦合，模块规模适中（不过大不过小，还要看模块间关系）
• 信息隐蔽：模块内部细节对外隐藏
• 模块功能应完整，消除重复功能，减少病态连接
• 错项特征："只根据模块功能确定规模大小" ← 错！还要看模块间关系
④ McCabe 环路复杂度（4 分，年年考）
公式：V(G) = E − N + 2 （E = 边的条数，N = 节点数）
等价公式：V(G) = 判定节点数 + 1
意义：V(G) 就是"需要测试的独立路径条数"，值越大程序越复杂。
例：某流图 E=11，N=10 → V(G) = 11 − 10 + 2 = 3。
验算：判定节点（有分叉的）有 2 个 → 2+1 = 3 ✓。
陷阱：数"边"和"节点"要仔细；或者直接数判定节点（菱形，出度≥2 的节点）再 +1，更快。
📐 例：流图怎么数
节点 N=6，边 E=7 → V(G)=7−6+2=3；判定节点是 2 和 4（共 2 个）→ 2+1=3 ✓
⑤ 软件测试（2+2+8+4 分）
V 模型：测试与开发阶段一一对应
| 开发阶段 | 对应测试 | 依据 |
|---|
| 需求分析 | 系统测试 / 验收测试 | 需求规格说明书 |
| 概要设计 | 集成测试 | 概要设计文档（测模块接口） |
| 详细设计 / 编码 | 单元测试 | 详细设计文档（测单个模块） |
🧠 题眼："发现模块之间接口问题" = 集成测试；"系统测试目标来自（）阶段" = 需求分析；"类测试相当于传统单元测试" = OO 里"单元"就是类。
📐 V 模型长啥样
左边往下开发，右边往上测试；同一水平线一一对应（需求↔验收、概设↔集成、详设↔单元）
黑盒测试 vs 白盒测试
| 黑盒测试 | 白盒测试 |
|---|
| 看什么 | 只看输入输出（不看内部） | 看内部逻辑结构 |
| 方法 | 等价类划分、边界值分析、因果图、错误推测 | 语句覆盖、判定覆盖、条件覆盖、路径覆盖 |
| 场景 | "分别输入 3499/3500/3501" → 边界值 | "覆盖所有语句/路径" → 白盒 |
白盒覆盖强度（从弱到强，必背）：
语句覆盖 < 判定覆盖 < 条件覆盖 < 判定/条件覆盖 < 条件组合覆盖 < 路径覆盖
问"覆盖程度最高" → 闭眼选【路径覆盖】。
语句覆盖最弱（只要每句跑一遍）；路径覆盖最强（所有可能路径都跑）。
测试阶段与"质量"
• 技术评审 = 主动质量管控（需求/设计/代码评审），能早期发现问题 → 提高质量
• 软件测试 = 事后缺陷验证 → 只能发现缺陷
• 金句："质量不是测出来的，是构建出来的"；问"提高质量"选评审，问"发现缺陷"选测试
⑥ 软件维护（7+6 分）
| 类型 | 触发原因 | 题眼 |
|---|
| 改正性维护 | 修 bug | 改正错误、修复缺陷 |
| 适应性维护 | 软硬件环境变化 | "OS 升级 / 新硬件 / 环境变化" |
| 改善性（完善性）维护 | 增加新功能、改进性能 | "用户提出新需求 / 功能增强" |
| 预防性维护 | 防止未来出问题 | "主动提高可维护性 / 为将来做准备" |
🧠 秒杀：环境变了 = 适应性；修 bug = 改正性；加功能 = 完善性；防未来 = 预防性。
可维护性公式：M = 1 / (1 + MTTR)（MTTR = 平均故障修复时间）
维护类型（按内容分）：程序维护 / 数据维护（对数据增删改）/ 代码维护 / 设备维护。题眼："对文件或数据中的记录增删改" = 数据维护。
⑦ 软件质量 & CMM（3+4 分）
CMM 能力成熟度模型（五级）
| 级别 | 名称 | 特征 |
|---|
| 1 | 初始级 | 混乱，靠个人英雄 |
| 2 | 可重复级 | 有基本项目管理，可重复成功经验 |
| 3 | 已定义级 | 过程标准化、文档化 |
| 4 | 已管理级 | 定量管理，有度量数据 |
| 5 | 优化级 | 持续改进 |
口诀：初始 → 可重复 → 已定义 → 已管理 → 优化
ISO/IEC 软件质量特性
六大特性：功能性、可靠性、易用性、效率、可维护性、可移植性。
可移植性子特性：适应性、易安装性、一致性、易替换性（不含"易测试性"——易测试性属可维护性）。
⑧ 自测 6 道（软工高频）
练 1：某系统需求明确且稳定，要求各阶段严格评审、文档齐全，最适合的开发模型是？
A. 原型模型 B. 螺旋模型 C. 瀑布模型 D. 敏捷
答案 C。需求明确稳定 + 文档驱动 + 严格评审 = 瀑布。
练 2：数据流图（DFD）的组成不包括？
A. 数据流 B. 外部实体 C. 数据存储 D. 控制流
答案 D。DFD 四要素 = 数据流 + 外部实体 + 加工 + 数据存储，没有控制流（那是程序流程图）。
练 3：两个模块通过一个外部（全局）变量交换输入输出信息，这种耦合是？
A. 数据耦合 B. 标记耦合 C. 控制耦合 D. 公共耦合
答案 D。共享"公共数据环境/全局变量" = 公共耦合。传简单数据=数据耦合；传记录=标记耦合；传开关标志=控制耦合。
练 4：某模块所有处理元素都在同一个数据结构上操作，其内聚类型是？
A. 逻辑内聚 B. 过程内聚 C. 通信内聚 D. 功能内聚
答案 C。"同一数据结构上操作" = 通信内聚。
练 5：下列测试方法中，覆盖程度最高的是？
A. 语句覆盖 B. 判定覆盖 C. 条件覆盖 D. 路径覆盖
答案 D。覆盖强度：语句 < 判定 < 条件 < 判定/条件 < 条件组合 < 路径。问最强选路径。
练 6：因操作系统升级，对软件进行修改，这属于哪种维护？
A. 改正性 B. 适应性 C. 改善性 D. 预防性
答案 B。软硬件环境变化 = 适应性维护。修 bug=改正性；加功能=完善性；防未来=预防性。
🎯 软件工程速记总表
| 考点 | 一句话 |
|---|
| 瀑布/螺旋/敏捷题眼 | 缺灵活=瀑布；风险分析=螺旋；快迭代=敏捷 |
| DFD 四要素 | 数据流、加工、数据存储、外部实体（无控制流） |
| 耦合（低→高） | 非→数→标→控→外→公→内 |
| 内聚（高→低） | 功→顺→通→过→时→逻→偶 |
| McCabe | V(G)=E−N+2 = 判定节点+1 |
| 覆盖强度 | 语句<判定<条件<路径（最强） |
| 提高质量 | 选"技术评审"，不是测试 |
| 维护四类 | 环境变=适应性；修bug=改正性；加功能=完善性；防未来=预防性 |
| CMM | 初始→可重复→已定义→已管理→优化 |