知识库
先学知识点，再做题检验。当前：软件工程
01. 计算机系统知识 (13个)
02. 程序语言基础 (3个)
03. 操作系统 (8个)
04. 软件工程 (8个)
05. 数据结构与算法 (23个)
06. 数据库系统 (11个)
07. 计算机网络 (12个)
08. 面向对象技术 (10个)
09. 信息安全 (4个)
10. 知识产权与标准化 (4个)
11. 多媒体基础 (2个)
12. 项目管理 (4个)
软件开发模型
开发模型对比
重点 难度 2/3
通俗理解
软件开发模型 = 做菜的不同流程策略。有人喜欢按菜谱一步步来（瀑布），有人喜欢先做一道菜尝一口再改进（迭代），有人喜欢一边买菜一边想做什么菜（敏捷）。
• 瀑布模型（做蛋糕）：先确定菜单→买齐材料→一次性做好整个蛋糕→最后才尝味道。前面错了一步，后面全白费。
• 原型模型（试吃）：先快速做一小份样品给顾客尝→改进了再做→再尝→直到满意再做正式版。
• 增量模型（拼图）：先做蛋糕底座→再做第一层奶油→再加装饰——每层都能独立交付使用。
• 螺旋模型（风险评估）：每次循环都做：计划→风险分析→开发→评价，像一个螺旋不断前进。
• 喷泉模型：面向对象的迭代——各阶段有重叠（不像瀑布严格分阶段）。
核心公式/考点
表格对比：六大开发模型
| 模型 | 核心思想 | 优点 | 缺点 | 适用场景 |
| 瀑布模型 | 线性顺序，阶段分明 | 文档完整，管理简单 | 修改成本高，用户后期才能见产品 | 需求明确稳定的项目 |
|---|---|---|---|---|
| 原型模型 | 快速构建+迭代改进 | 能及早发现需求偏差 | 用户可能急于求成、原型影响质量 | 需求不明确的项目 |
| 增量模型 | 分块开发、逐步交付 | 早期交付部分功能 | 需要良好的总体规划 | 大型系统分版本发布 |
| 螺旋模型 | 风险驱动、循环迭代 | 风险控制强 | 复杂、成本高、管理难度大 | 高风险项目 |
| 喷泉模型 | 面向对象、阶段重叠 | 开发效率高、复用性强 | 管理难度大、文档管理复杂 | 面向对象项目 |
| 敏捷开发 | 迭代增量+快速响应变化 | 响应需求变化快、客户满意度高 | 文档较少、对团队要求高 | 需求变化频繁的项目 |
真题演练
例题1：（软考真题）适合需求不明确、开发难度较大的项目，且强调风险分析的开发模型是？
A.瀑布模型 B.原型模型 C.螺旋模型 D.增量模型
解：
A❌ 瀑布模型要求需求明确，不适合需求不明确
B❌ 原型模型适合需求不明确，但不强调风险分析
C✅ 螺旋模型=风险驱动+循环迭代，适合高风险、需求不明确的大型项目
D❌ 增量模型需要总体规划，不完全适合需求不明确的场景
选C。
例题2：（经典题）以下哪个模型的特征包含"计划→风险分析→开发→评价"的循环？
解：螺旋模型的每一圈都包含这四个阶段。螺旋模型从内圈到外圈，每圈风险降低、投入增加。
注意事项
⚠️ 易错点1：瀑布模型虽然有"反馈环"概念，但本质上还是线性顺序的，各阶段之间修改困难。
⚠️ 易错点2：原型模型"快速构造原型"不代表最终产品质量差——原型是用于探索需求的工具。
⚠️ 易错点3：螺旋模型的"风险分析"是其核心特色——其他模型没有明确的风险评估环节。
⚠️ 易错点4：增量模型和迭代模型的区别——增量是"分块交付功能"，迭代是"每轮完善全部功能"。
⚠️ 易错点5：喷泉模型专为面向对象设计——特点是无缝衔接、阶段重叠、对象复用。
⚠️ 易错点6：没有"放之四海而皆准"的最佳模型——要根据项目特点（需求明确度、风险、团队经验）选择。
敏捷开发Scrum
重点 难度 2/3
通俗理解
Scrum = 一个小团队（7±2人）每2~4周冲刺一个小目标，每天早上站会同步进度，完成后回顾改进。
就像组装乐高玩具：
• 产品待办列表（Product Backlog）→乐高说明书上的所有步骤清单
• Sprint冲刺→你决定"这周我要拼好赛车的前半部分"
• Sprint待办列表→这一周要拼的具体零件清单
• 每日站会→每天早晨花15分钟说："我昨天拼了轮子、今天拼车身、没有障碍"
• Sprint评审→展示你做好的赛车前半部分
• Sprint回顾→"下回拼大城堡我们要...改进XX"
核心公式/考点
Scrum核心角色：
| 角色 | 职责 | 类比 |
| Product Owner（产品负责人） | 管理Product Backlog、排优先级、代表客户 | 项目出资人/客户代表 |
|---|---|---|
| Scrum Master | 保障Scrum流程正确执行、排除障碍 | 教练/项目经理 |
| 开发团队（Developers） | 自组织完成Sprint目标 | 建筑工/程序员 |
Scrum核心事件（按时间顺序）：
1.Sprint Planning（冲刺计划会）→确定本次Sprint目标和待办项
2.Daily Scrum（每日站会）→15分钟，三问题：昨天做了什么？今天做什么？有什么困难？
3.Sprint Review（冲刺评审会）→展示完成的成果，收集反馈
4.Sprint Retrospective（冲刺回顾会）→团队自我改进，找到可优化的流程
Scrum核心工件：
• Product Backlog（产品待办列表）：所有要开发的功能的优先级列表，由PO维护
• Sprint Backlog（冲刺待办列表）：本次Sprint要完成的任务
• Increment（增量）：每个Sprint结束时交付的可工作的产品增量
表格对比：敏捷 vs 传统瀑布
| 维度 | 敏捷（Agile） | 传统瀑布（Waterfall） |
| 需求 | 需求变化是常态 | 需求提前确定且稳定 |
|---|---|---|
| 交付周期 | 每2~4周交付可运行增量 | 最后一次性交付 |
| 团队组织 | 自组织小团队（5~9人） | 按职能分工（分析→设计→编码→测试） |
| 沟通方式 | 面对面沟通为主 | 文档驱动 |
| 变更响应 | 欢迎变更 | 严格控制变更 |
| 客户参与 | 客户紧密参与全过程 | 客户主要在开始和结束参与 |
| 测试 | 持续测试（TDD/CI） | 阶段末集中测试 |
真题演练
例题1：（软考真题）在Scrum中，负责维护Product Backlog并确定其优先级的是？
A.Scrum Master B.开发团队 C.Product Owner D.项目经理
解：
A❌ Scrum Master负责流程，不负责产品内容
B❌ 开发团队自组织完成任务，但不决定优先级
C✅ Product Owner代表客户，负责管理Product Backlog，排优先级
D❌ Scrum中没有"项目经理"这个角色
选C。
例题2：（概念题）Daily Scrum（每日站会）的主要目的是？
解：每日站会的目的是同步信息、识别障碍、调整计划。不是做详细的问题分析，不是向领导汇报，不是解决问题本身——解决问题是会后的事。
注意事项
⚠️ 易错点1：每日站会不是"向Scrum Master汇报"——开发团队是自组织的，站会是为了团队内部同步。
⚠️ 易错点2：Sprint期间不能随意变更Sprint Backlog的内容（除非和PO协商），这是Sprint的稳定性保障。
⚠️ 易错点3：Scrum Master不是传统意义上的"项目经理"——他是服务型领导，为团队排除障碍。
⚠️ 易错点4：Sprint的长度一般2~4周，固定不变，不能因为任务多就加长Sprint，而是减少本次Sprint的任务量。
⚠️ 易错点5：Sprint Retrospective（回顾）和Sprint Review（评审）不同——评审面向产品（检视增量），回顾面向过程（团队改进）。
⚠️ 易错点6：敏捷开发不止Scrum——还有XP（极限编程）、Kanban（看板）等，Scrum是最流行的框架。
设计原则
内聚与耦合
重点 难度 2/3
通俗理解
内聚和耦合是衡量软件模块设计质量的两个核心指标——就像评价一个团队的工作效率：
• 高内聚：团队内部每个人都配合默契、目标一致（模块内部功能相关性强）
• 低耦合：团队之间各干各的、很少互相扯皮（模块之间依赖少、接口清晰）
理想设计：高内聚 + 低耦合
内聚（Cohesion）——从差到好排序：
想象一个工具箱里的工具：
1.🚫 偶然内聚（最差）：一把螺丝刀+一个球拍+一根筷子——放进一个盒子里只是"碰巧放在一起"
2.🔄 逻辑内聚：把"所有工具的加固部分"归类——不合理，工具用途不同
3.🕐 时间内聚：把"早上8点用的所有工具"放一起——不合理，只是时间相同
4.📦 过程内聚：把"修理自行车第一步骤所需的工具"放一起——有点关联
5.📡 通信内聚：把"修剪树枝和嫁接树木的工具"放一起——处理同一数据
6.🎯 顺序内聚：螺丝刀→螺丝→钻头→电钻？不是，应该是处理流程中先后步骤的工具
7.💡 功能内聚（最好）：一把"修剪树枝的剪刀"——每个部件都服务于"修剪"这个单一功能
核心公式/考点
内聚从低到高排序（必考排序题）：
偶然内聚（最差）< 逻辑内聚 < 时间内聚 < 过程内聚 < 通信内聚 < 顺序内聚 < 功能内聚（最好）
耦合（Coupling）——从好到差排序：
1.✅ 非直接耦合：两个模块没关系
2.✅ 数据耦合：只通过参数传数据（最好）
3.⚠️ 标记耦合：传数据结构（如传整个结构体）
4.⚠️ 控制耦合：传控制标志（一个模块控制另一个模块的逻辑）
5.❌ 外部耦合：共享外部约束（如同一条文件格式）
6.❌ 公共耦合：共享全局数据区（如全局变量）
7.❌❌ 内容耦合（最差）：一个模块直接访问另一个模块的内部数据
表格对比：内聚与耦合
| 内聚类型 | 级别 | 含义 |
| 功能内聚 | ⭐⭐⭐（最好） | 模块内所有元素完成一个单一功能 |
|---|---|---|
| 顺序内聚 | ⭐⭐ | 处理元素相关且顺序执行 |
| 通信内聚 | ⭐⭐ | 操作同一数据集的元素 |
| 过程内聚 | ⭐ | 按特定顺序执行 |
| 时间内聚 | ⭐ | 在相同时间执行 |
| 逻辑内聚 | ⭐ | 执行逻辑上相关的功能 |
| 偶然内聚 | 最差 | 无明确关联的代码放在一起 |
| 耦合类型 | 级别 | 含义 |
| 内容耦合 | ❌❌❌最差 | 直接访问对方内部 |
|---|---|---|
| 公共耦合 | ❌❌ | 共享全局变量 |
| 外部耦合 | ❌❌ | 共享外部格式/协议 |
| 控制耦合 | ⚠️ | 传控制标志 |
| 标记耦合 | ⚠️ | 传整个数据结构 |
| 数据耦合 | ✅最好 | 仅传必要的数据参数 |
| 非直接耦合 | ✅✅ | 模块间无任何联系 |
真题演练
例题1：（软考真题）模块A将学生信息结构体直接传给模块B，两个模块之间的耦合类型是？
A.数据耦合 B.标记耦合 C.控制耦合 D.公共耦合
解：
A❌ 数据耦合——只传基本数据参数（如int id），这里传了整个结构体
B✅ 标记耦合——传递的是整个数据结构（记录/结构体），不是单个基本类型数据
C❌ 控制耦合——传控制标志来控制逻辑
D❌ 公共耦合——通过全局变量共享
选B。
例题2：（经典题）以下关于内聚的描述，正确的是？A.逻辑内聚比通信内聚好 B.功能内聚是最理想的内聚 C.偶然内聚是好的 D.时间内聚是最差的
解：
A❌ 内聚排序：功能>顺序>通信>过程>时间>逻辑>偶然。逻辑内聚（差）< 通信内聚（好）
B✅ 功能内聚是最高级别的内聚，最理想
C❌ 偶然内聚是最差的内聚
D❌ 最差的是偶然内聚
选B。
注意事项
⚠️ 易错点1：内聚从高到低排序是常考知识点，一定要记住7种内聚的排序！
⚠️ 易错点2：耦合从低到高（好到差）：非直接→数据→标记→控制→外部→公共→内容。
⚠️ 易错点3：数据耦合传"基本类型参数"，标记耦合传"整个数据结构"——区别在于传的是什么类型。
⚠️ 易错点4：模块独立性 = 高内聚 + 低耦合。但追求极致的数据耦合和功能内聚有时不现实，需要权衡。
⚠️ 易错点5：内容耦合是最高级别的耦合（最差）——一个模块直接修改另一个模块的内部数据，违反了信息隐藏原则。
⚠️ 易错点6：模块设计原则：降低耦合提高内聚——这是软件设计中最根本的指导原则之一。
软件测试
白盒测试
重点 难度 2/3
通俗理解
白盒测试 = 把软件当成"透明盒子"——测试人员能看到内部代码和逻辑结构，针对性地设计测试用例，覆盖所有可能的路径和条件。
就像老师批改数学题：
• 黑盒测试：只看最终答案对不对（输入→输出）
• 白盒测试：看解题步骤，检查每一步是否正确、有没有漏掉分支情况
核心公式/考点
白盒测试六大覆盖方法（从弱到强）：
| 覆盖方法 | 覆盖准则 | 强度 | 说明 |
| 语句覆盖 | 每条可执行语句至少执行一次 | ⭐ | 最弱，不能覆盖分支条件 |
|---|---|---|---|
| 判定覆盖（分支覆盖） | 每个判定的真/假分支至少各一次 | ⭐⭐ | 每个if都走一次真一次假 |
| 条件覆盖 | 每个条件的所有可能值至少一次 | ⭐⭐ | 关注每个原子条件取真取假 |
| 判定-条件覆盖 | 同时满足判定覆盖+条件覆盖 | ⭐⭐⭐ | 两者结合 |
| 条件组合覆盖 | 所有条件组合至少一次 | ⭐⭐⭐⭐ | 最全面但用例数指数增长 |
| 路径覆盖 | 覆盖所有可能的执行路径 | ⭐⭐⭐⭐⭐ | 最强但实际做不到（路径爆炸） |
逻辑覆盖强度排序：
语句覆盖 < 判定覆盖 < 条件覆盖 < 判定-条件覆盖 < 条件组合覆盖 < 路径覆盖
McCabe圈复杂度计算（衡量程序复杂度的指标）：
公式1：V(G) = E - N + 2（E=边数，N=结点数）
公式2：V(G) = 判定结点数 + 1
公式3：V(G) = 区域数（有向图将平面分割的区域数）
圈复杂度 = 最少需要的测试用例数（基本路径数）
真题演练
例题1：（软考真题）if (A>1 && B==0) { X=1; } else { X=2; } 要实现判定覆盖，最少需要几个测试用例？
解：
1.判定节点只有一个：if(A>1 && B==0)
2.判定覆盖要求该判定取真和取假各一次
3.真分支：A>1且B==0 → 如A=2,B=0
4.假分支：A≤1或B≠0 → 如A=0,B=0
5.最少需要2个测试用例
注意：这里的"假"是整个条件表达式结果为假，不要求每个原子条件都覆盖到（那是条件覆盖）。
例题2：（经典题）计算下面流程图的McCabe圈复杂度：
（流程图有1个开始结点、1个结束结点、3个判定结点、若干处理结点，边数8，结点数6）
解：
方法1：V(G)=E-N+2=8-6+2=4
方法2：判定结点数=3→V(G)=3+1=4
方法3：区域数=4
所以圈复杂度=4，最少需要4个基本路径测试用例。
注意事项
⚠️ 易错点1：语句覆盖最弱但最基础——它连"判定为假"的分支都保证不了覆盖。
⚠️ 易错点2：100%语句覆盖≠100%分支覆盖——没有分支的代码也能100%语句覆盖。
⚠️ 易错点3：条件组合覆盖的用例数 = 2^(条件个数)（如果所有条件独立），随条件数指数增长。
⚠️ 易错点4：路径覆盖在理论上完美但实践中几乎不可能——循环就会产生无限多条路径。
⚠️ 易错点5：McCabe圈复杂度不仅用于度量测试用例数，也是评估程序可测试性和可维护性的指标——复杂度大于10通常建议重构。
⚠️ 易错点6：基本路径测试是McCabe提出的方法——根据圈复杂度确定独立路径数量，然后设计测试用例。
黑盒测试
重点 难度 2/3
通俗理解
黑盒测试 = 把软件当成"不透明的黑盒子"——不看内部代码，只关心输入什么、输出什么。就像汽车试驾——你不关心发动机内部怎么工作，只管踩油门看速度、打方向盘看转弯。
常见的黑盒测试方法：
• 等价类划分：把无数种输入分成几个"等价类"——测试一个等于测试一类
• 边界值分析：程序最容易在边界处出错——重点测试边界附近的值
• 因果图法：分析输入条件（因）和输出结果（果）的组合关系
• 错误推测法：根据经验猜测哪些地方容易出错
• 功能图法：用状态迁移图测试功能
核心公式/考点
表格对比：黑盒测试主要方法
| 方法 | 核心思想 | 优点 | 缺点 |
| 等价类划分 | 输入按有效/无效分类，每类取一个代表 | 用例少、覆盖面广 | 不能覆盖边界问题 |
|---|---|---|---|
| 边界值分析 | 重点测边界（最小值、最大值、边界+1/-1） | 发现边界错误的效率高 | 不了解等价类的前提需等价类辅助 |
| 因果图法 | 输入条件→输出结果的关系组合 | 能发现组合条件导致的缺陷 | 需要分析输入关系，复杂 |
| 错误推测法 | 凭经验猜哪里容易出错 | 针对性强 | 依赖测试人员经验 |
| 正交试验法 | 用正交表设计最小测试组合 | 测试组合最优化 | 需要正交表知识 |
等价类划分步骤：
1.确定输入条件（需求规格）
2.划分有效等价类（能正确处理的输入）
3.划分无效等价类（不能正确处理的输入）
4.为每个等价类设计测试用例
边界值分析原则：
• 取最小值、略大于最小值、正常值、略小于最大值、最大值
• 对取值范围为[a,b]的输入，测试a、a+1、中间值、b-1、b
• 比等价类划分更能发现错误（经验证明：边界附近出错率最高）
真题演练
例题1：（软考真题）需求规定"输入的整数在1~100之间"，使用边界值分析法，至少需要几个测试输入？
解：
边界值分析测试点：0（下界-1）、1（下界）、2（下界+1）、99（上界-1）、100（上界）、101（上界+1）
→ 至少6个测试输入
但如果用边界的"最简版本"：1、100、0、101（4个）
实际上不同教材标准略有不同，常用的是{0,1,2,99,100,101}共6个。
标准答案通常取5~6个：最小值、最大值、最小值-1、最大值+1、有效范围内的一个值。
例题2：（经典题）年龄输入框规定0~150岁。用等价类划分法，如何设计测试用例？
解：
1.有效等价类：0~150之间的整数（1个类，取中间值如25）
2.无效等价类：
小于0的整数（如-1）
大于150的整数（如200）
非整数（如12.5）
非数字字符（如"abc"）
3.每个等价类至少一个测试用例
例题3：（概念题）等价类划分和边界值分析的区别和联系？
答：等价类划分划分类别、每类一个代表用例；边界值分析关注类边界附近的值，是为了补充等价类划分覆盖不了边界问题的缺陷。通常两种方法结合使用。
注意事项
⚠️ 易错点1：等价类划分"每个有效类和无效类至少一个用例"——不要遗漏无效类！
⚠️ 易错点2：等价类不是单一的——一个输入可能有多个有效等价类（如"性别"的"男"和"女"都是有效类）。
⚠️ 易错点3：边界值分析通常和等价类划分配合使用——先分等价类，再对每个类做边界值分析。
⚠️ 易错点4：边界值不仅要测试输入边界，也要测试输出边界（如分页显示的边界）。
⚠️ 易错点5：因果图法适合有多个输入条件组合的场景（如"如果余额充足且密码正确→扣款成功"）。
⚠️ 易错点6：白盒测试和黑盒测试不是对立关系——实际项目中两者互补，都要做。
维护与质量
软件维护四类型
重点 难度 2/3
通俗理解
软件维护 = 软件交付使用后，"修修补补、升级优化"的持续过程。就像你买了房子之后的日常维护：
• 纠正性维护：水管漏水了→修好（修复bug）
• 适应性维护：小区改用了新的电力标准→改造电路（适应环境变化）
• 完善性维护：想把阳台改成阳光房→加装玻璃（增加新功能）
• 预防性维护：检查电路老化，提前更换→防止以后出问题（防患于未然）
核心公式/考点
表格对比：四种维护类型
| 类型 | 定义 | 触发原因 | 占比 | 类比 |
| 纠正性维护 | 修复已发现的错误和缺陷 | Bug报告、系统崩溃 | ~20% | 漏水了修水管 |
|---|---|---|---|---|
| 适应性维护 | 适应外部环境变化而修改 | 操作系统升级、数据库版本变更 | ~25% | 换新水管接头 |
| 完善性维护 | 增加新功能或改进性能 | 用户需求变更、想做得更好 | ~50% | 装修升级厨房 |
| 预防性维护 | 预防未来可能发生的问题 | 未雨绸缪、代码重构 | ~5% | 定期检查电路 |
维护费用占比分布图（经典统计）：
完善性维护 ≈ 50%（最大头！）
适应性维护 ≈ 25%
纠正性维护 ≈ 20%
预防性维护 ≈ 5%
所以软件维护中，最大工作量不是"修bug"，而是"加功能和适应新环境"！
真题演练
例题1：（软考真题）因操作系统版本升级，需要修改某软件以适应新系统API，这属于？
A.纠正性维护 B.适应性维护 C.完善性维护 D.预防性维护
解：
A❌ 纠正性维护是修bug，这里没有bug
B✅ 操作系统升级是外部环境变化（API变了），软件需要修改以适配新环境——典型的适应性维护
C❌ 完善性维护是增加新功能或改进性能
D❌ 预防性维护是为防止未来问题所做的预防措施
选B。
例题2：（经典题）以下哪种维护在软件维护中占比最大？A.纠正性 B.适应性 C.完善性 D.预防性
解：统计表明完善性维护约占50%，是最大头。选C。
例题3：（概念题）对软件中"可能存在隐患的代码段进行重构"属于哪种维护？
解：重构目的是提高代码质量和可维护性，防止未来出问题，属于预防性维护。预防性维护是最容易被忽视但长期来看最有价值的维护类型。
注意事项
⚠️ 易错点1：完善性维护不是"修复bug"！纠正性维护才是修bug的。
⚠️ 易错点2：适应性维护的"外部环境变化"包括：操作系统、数据库、硬件、网络协议、法律法规等。
⚠️ 易错点3：完善性维护≈50%占比是经典统计数字，考试常考——不要和纠正性维护(≈20%)混淆。
⚠️ 易错点4：预防性维护在传统维护分类中占比最小（~5%），但随着DevOps和持续重构的理念普及，其重要性日益增加。
⚠️ 易错点5：还有一种不太常见的"紧急维护"——需要紧急修复严重影响业务的bug，属于纠正性维护的子类。
⚠️ 易错点6：软件维护的难度和成本往往被低估——整个软件生命周期中，维护阶段占约60%~80%的总成本。
数据流图DFD
数据流图DFD基础
重点 难度 2/3
通俗理解
数据流图（DFD）= 软件系统的"数据地图"——用图形化的方式展示数据从哪里来、经过哪些加工、存到哪里、最后流向哪里。
就像快递物流系统：
• 外部实体（External Entity）：发件人/收件人——数据来源或终点
• 加工（Process）：分拣中心——数据处理/转换的地方
• 数据存储（Data Store）：仓库/货架——数据存放的地方
• 数据流（Data Flow）：快递包裹在流转——数据从一处到另一处的移动
核心公式/考点
DFD四大基本元素（必考）：
| 元素 | 图形符号 | 含义 | 命名规则 |
| 外部实体 | 矩形 | 系统外部的人/组织/系统 | 名词（如"客户"） |
|---|---|---|---|
| 加工 | 圆形/圆角矩形 | 对数据进行的处理/变换 | 动词+名词（如"审核订单"） |
| 数据存储 | 开口矩形（右边开口的长条） | 数据暂存的地方 | 名词（如"订单表"） |
| 数据流 | 带箭头的线 | 数据在元素间流动的方向 | 名词（如"订单信息"） |
DFD分层体系：
• 顶层图（上下文图/0层图）：一个圆圈代表整个系统，外部实体通过数据流与系统交互
• 0层图（系统基本模型）：把顶层图的系统功能分解为几个主要加工
• 子图：对0层图中的每个加工进一步细化
DFD建模原则（核心考点）：
1.父图与子图的平衡原则：父图的输入输出数据流必须在子图中完整出现（数据流守恒）
2.数据守恒原则：加工必须有输入数据流和输出数据流（不能只有输入或只有输出）
3.加工编号规则：顶层图→加工0（或系统名），0层图→1，2，3...，子图→1.1，1.2...
4.非命名原则：数据流不能重名但含义不同
5.
真题演练
例题1：（软考真题）以下关于数据流图（DFD）的描述，错误的是？
A.加工必须有输入和输出数据流
B.父图和子图的数据流必须平衡
C.外部实体可以是另一个系统
D.数据存储可以没有输入数据流
解：
A✅ 加工的作用是"将输入数据转换为输出数据"——两者缺一不可
B✅ 父图某加工的数据流必须与子图的输入输出完全一致（数据流守恒）
C✅ 外部实体可以是人、组织或另一个系统
D❌ 数据存储也必须有输入（写）和输出（读）数据流才能有意义——不可能只有读没有写
选D。
例题2：（经典题）DFD中，以下哪项不属于基本元素？A.数据流 B.加工 C.程序模块 D.数据存储
解：DFD四大基本元素：外部实体、加工、数据存储、数据流。程序模块是结构化设计（SC图/结构图）中的概念，不是DFD的元素。选C。
例题3：（概念题）顶层DFD（上下文图）通常包含几个加工？
解：顶层图将整个系统抽象为一个加工，作用是用一个圆圈表示整个系统，展示系统与外部实体的所有数据交互。所以顶层图有且只有1个加工（代表整个系统）。
注意事项
⚠️ 易错点1：加工必须有"输入+输出"数据流——不能只有输入（那样数据从哪来？），不能只有输出（数据从哪来？）。
⚠️ 易错点2：父图与子图的平衡——子图的输入输出数据流（作为一个整体）必须和父图对应加工的数据流完全一致。
⚠️ 易错点3：数据流必须有方向——单向箭头！数据不会自动"两边流"。
⚠️ 易错点4：数据存储是"被动"的——没有加工操作数据存储时它什么都不做。
⚠️ 易错点5：DFD和结构图（SC/Structure Chart）不同——DFD描述"数据流"（功能建模），SC描述"模块调用关系"（结构设计）。
⚠️ 易错点6：画DFD时，数据的流向反映的是业务逻辑流程，不是程序执行流程——两者有本质区别。
⚠️ 易错点7：外部实体之间、数据存储之间不能有直接数据流——数据必须经过加工处理才能流动。
设计原则
软件质量模型ISO 9126
重点 难度 2/3
通俗理解
ISO 9126 = 评价软件"好坏"的六维标准体系。就像评价一辆车——不能只说"好开"，而要从安全性、舒适性、油耗、空间等多方面综合评估。
评价软件就像评价一个外卖App：
• 功能性（Functionality）：能不能点餐、支付、查看订单？（功能是否完整正确）
• 可靠性（Reliability）：会不会经常闪退、下单失败？（稳定运行不出错）
• 易用性（Usability）：好不好操作？老年人会用吗？（用户友好）
• 效率（Efficiency）：点餐快吗？图片加载慢不慢？（性能好）
• 可维护性（Maintainability）：出bug了程序员好改吗？加新功能容易吗？（维护方便）
• 可移植性（Portability）：能在安卓、iOS、Web上跑吗？（跨平台能力）
核心公式/考点
ISO/IEC 9126 质量模型（已更新为ISO 25010，但软考常考9126）：
六大特性及子特性：
| 特性 | 含义 | 子特性 |
| 功能性 | 满足用户需求的功能 | 适合性、准确性、互操作性、安全保密性、功能依从性 |
|---|---|---|
| 可靠性 | 在特定条件下维持性能水平 | 成熟性、容错性、易恢复性 |
| 易用性 | 用户使用的容易程度 | 易理解性、易学性、易操作性、吸引性 |
| 效率 | 在给定条件下性能与资源比 | 时间行为（响应时间）、资源利用率 |
| 可维护性 | 修改的容易程度 | 易分析性、易改变性、稳定性、易测试性 |
| 可移植性 | 从一种环境迁移到另一种环境 | 适应性、易安装性、共存性、易替换性 |
McCall质量模型（另一种经典模型）：
三大视角：产品运行（正确性、可靠性、效率、完整性、可用性）、
产品修正（可维护性、灵活性、可测试性）、
产品转移（可移植性、复用性、互操作性）
表格对比：ISO 9126 vs McCall
| 维度 | ISO 9126 | McCall |
| 发布时间 | 1991（ISO标准） | 1977（美国空军） |
|---|---|---|
| 层次结构 | 特性→子特性→度量指标 | 因素→准则→度量 |
| 特性数 | 6个特性，27个子特性 | 11个质量因素 |
| 分类视角 | 用户/开发者/管理者视角 | 产品运行/修正/转移 |
| 典型应用 | 软件质量评价与度量 | 早期质量保证框架 |
真题演练
例题1：（软考真题）软件在异常条件下能继续提供服务的特性属于？A.功能性 B.可靠性 C.可用性 D.健壮性
解：
A❌ 功能性指功能是否满足需求，不是异常处理能力
B✅ 可靠性的子特性包括"容错性"——在异常条件下维持运行
C❌ 可用性是易用性的一个子特性（指能否用、好不好用）
D❌ 健壮是"容错性"的通俗说法，归在可靠性维度下
选B。
例题2：（经典题）ISO 9126模型中，以下哪个属于"可维护性"的子特性？
A.易分析性 B.容错性 C.易学性 D.适应性
解：
A✅ 易分析性（分析定位问题的难度）属于可维护性
B❌ 容错性属于可靠性
C❌ 易学性属于易用性
D❌ 适应性属于可移植性
选A。
注意事项
⚠️ 易错点1：ISO 9126的六大特性要能准确配对子特性——高频考点。
⚠️ 易错点2：可靠性和可用性(易用性)的区别——可靠性是"会不会出错"，易用性是"好不好用"。
⚠️ 易错点3：效率和性能的区别——效率=性能/资源比，不只是速度快。
⚠️ 易错点4：ISO 9126已被ISO 25010取代，但考试仍考9126的特征。
⚠️ 易错点5：安全性（Security）在ISO 9126中是功能性的子特性（安全保密性），在ISO 25010中提升为独立特性。
⚠️ 易错点6：McCall模型的11个因素和三大视角也要适当了解，有时会考对比。