文章目录
- 1.CMMI vs CMM
- 2.功能需求 vs 非功能需求
- 3.四大运维/可靠性核心指标（MTBF、MTTR、MTTF、MTTA）
- 4.数字签名
- 5 uml图的别称
- 6.需求/估算/预测常用方法 对照表
- 7.需求获取 / 需求分析 / 需求验证
- 8.发明专利 vs 实用新型专利
- 9.未提交读 > 提交读 > 可重复读 > 串行化
- 10. 数据库事务三大问题 + 隔离级别 终极速记表
- 11.防火墙全分类（按工作层级/实现方式）
- 12.软件需求编写避坑清单（核心版）
- 13 系统分析阶段主要产出系统需求规格说明书
- 14.BAM
本节所有易错知识点均来源于2025年11月真题
1.CMMI vs CMM
CMM 是早期只做软件的旧模型；CMMI 是它的全面升级版，集成多领域、更灵活、现在只用 CMMI。
基本定义与关系
- CMM：Capability Maturity Model for Software，软件能力成熟度模型，1991年发布，只针对软件开发。
- CMMI：Capability Maturity Model Integration，能力成熟度模型集成，2000年后推出，CMM 的升级与整合版，合并了软件、系统工程、采购等多个模型。
- 关系：CMMI 取代了 CMM，CMM 已淘汰，现在认证/评估全是 CMMI。
核心区别（一眼看懂）
| 覆盖范围 | 仅软件开发 | 软件、系统、硬件、服务、采购（多领域集成） |
| 模型结构 | 只有阶段式（必须1→5级逐级升） | 双模式：阶段式（5级）+ 连续式（按过程域独立提升） |
| 过程域数量 | 18个（纯软件） | 25个（覆盖多领域） |
| 成熟度等级 | 5级：初始、可重复、已定义、已管理、优化 | 5级：初始、已管理、已定义、定量管理、优化（名字微调，更强调量化） |
| 适用开发模式 | 偏重瀑布模型 | 支持敏捷、迭代、DevOps，更灵活 |
| 评估与认证 | 旧评估方法，已停用 | 新评估方法，全球通用，现在只认 CMMI 证书 |
CMM（软件能力成熟度模型）分为5个等级，核心特征如下：
| 1级 | 初始级 | 过程混乱，依赖个人能力 |
| 2级 | 可重复级（管理级） | 建立了基本项目管理过程 |
| 3级 | 已定义级 | 过程标准化、文档化 |
| 4级 | 已管理级（定量管理级） | 对过程进行量化管理和控制 |
| 5级 | 优化级 | 持续过程改进，定量分析与优化 |
“定量分析与持续优化”正是 CMM 第5级（优化级） 的核心特征，这是CMM的最高成熟度等级，强调基于数据驱动的持续改进。
2.功能需求 vs 非功能需求
功能需求 ✅ 肉眼可见、用户能操作 ✅ 系统有什么功能、能干嘛 例：登录、下单、删除、导出、审批
非功能需求 ✅ 肉眼看不见、后台底层 ✅ 系统好不好用、稳不稳、快不快、安不安全 例：性能、并发、响应速度、安全、容错、高可用、可维护
- 页面能导出Excel → 功能（看得见）
- 导出不能超过2秒 → 非功能（看不见）
- 账号密码登录 → 功能
- 密码加密存储 → 非功能
- 新增病历 → 功能
- 系统全年99.99%可用 → 非功能
看得见的操作 = 功能需求 看不见的底层质量 = 非功能需求
3.四大运维/可靠性核心指标（MTBF、MTTR、MTTF、MTTA）
| MTTF | 平均失效前时间 | 不可修复（硬件/耗材，坏了直接换） | 正常运行总时长
÷ \\boldsymbol{\\div} ÷ 故障次数 |
越大越好 |
| MTBF | 平均故障间隔 | 可修复（软件/服务/集群，修好继续用） | (运行总时长 − 故障停机总时长)
÷ \\boldsymbol{\\div} ÷ 故障次数 |
越大越好 |
| MTTR | 平均修复时间 | 故障恢复耗时 | 故障停机总时长
÷ \\boldsymbol{\\div} ÷ 故障次数 |
越小越好 |
| MTTA | 平均确认时间 | 发现故障耗时 | 告警到确认总时长
÷ \\boldsymbol{\\div} ÷ 故障次数 |
越小越好 |
MTTF 设备坏了不修、直接报废，只有「运行时间」，没有修复环节。
MTBF（重点） 可修复系统：
M
T
B
F
=
正常运行总时间
故障次数
\\boldsymbol{MTBF = \\frac{\\text{正常运行总时间}}{\\text{故障次数}}}
MTBF=故障次数正常运行总时间 = 两次故障之间，平稳干活的时间
可用性标准公式（必考）
可用性
=
M
T
B
F
M
T
B
F
+
M
T
T
R
\\text{可用性} = \\frac{MTBF}{MTBF + MTTR}
可用性=MTBF+MTTRMTBF
举个例子秒懂 某服务：
- 30天内，故障2次
- 每次维修 2h，总停机
4
h
4\\ \\text{h}
4 h - 总时长：
30
×
24
=
720
h
30 \\times 24 = 720\\ \\text{h}
30×24=720 h - 正常运行时长：
720
−
4
=
716
h
720 – 4 = 716\\ \\text{h}
720−4=716 h
M
T
B
F
=
716
÷
2
=
358
h
M
T
T
R
=
4
÷
2
=
2
h
\\begin{align*} MTBF &= 716 \\div 2 = 358\\ \\text{h} \\\\ MTTR &= 4 \\div 2 = 2\\ \\text{h} \\end{align*}
MTBFMTTR=716÷2=358 h=4÷2=2 h
- MTBF：两次故障中间，能安稳跑多久
- MTTR：坏了之后，多久修好
- 一个管「多久不坏」，一个管「坏了修多快」
4.数字签名
数字签名技术的核心作用，是用发送方的私钥对数据摘要进行加密，接收方用公钥解密验证，以此实现： A. 数据完整性：摘要校验可以发现数据是否被篡改 C. 发送方身份认证：只有发送方持有私钥，签名可验证身份 D. 发送方不可抵赖性：签名由私钥生成，发送方无法否认发送过数据
但数字签名不对原始数据本身加密，只加密摘要，所以数据本身是明文传输的，无法直接保证数据保密性。要实现保密性，需要额外配合对称或非对称加密算法。
5 uml图的别称
序列图（也叫时序图或者顺序图）和通信图（也叫协作图）是可以相互转化的
交互概览图 = 活动图 + 序列图（交互图）的结合体 外层：活动图 → 管 “大流程、分支、循环、并发” 内层：序列图 → 管 “这一步里对象之间怎么发消息、谁先谁后”
6.需求/估算/预测常用方法 对照表
需求获取 完整6大官方方法（含JRP）
| 1. 访谈 | 一对一、深度聊 | 单独沟通业务人员 |
| 2. 问卷调查 | 大范围、批量收集 | 用户多、需求简单 |
| 3. 观察法 | 现场看、跟着做 | 业务复杂、用户讲不清 |
| 4. 头脑风暴 | 集体发散、脑洞 | 创意、新需求挖掘 |
| 5. JRP 联合需求计划（联合获取） | 各方集中开会、一起定需求 | 开发+业务+客户 集中参会，快速对齐 |
| 6. 原型法 | 先做Demo、边用边改 | 用户需求模糊、说不清 |
- 不想见面、防权威 → 德尔菲
- 集体脑洞想点子 → 头脑风暴
- 各方坐一起对齐需求 → JRP联合获取
- 一对一深入聊 → 访谈
- 用户说不清楚 → 原型
| 德尔菲法 | 匿名、多轮反馈、专家独立、无面对面 | 匿名、专家、多轮、收敛 | 长期预测、需求模糊、风险评估、新技术评估 |
| 头脑风暴 | 开会畅所欲言、自由发散、不反驳 | 创意、发散、快速想法收集 | 需求挖掘、问题 brainstorm、方案创意 |
| 名义小组技术 | 先独立思考→集体讨论→投票排序 | 独立+集中+投票 | 多方案择优、意见统一 |
| 访谈法 | 一对一、面对面沟通用户 | 一对一、深度沟通 | 精准需求收集、复杂业务调研 |
| 问卷调查 | 批量、标准化问卷 | 大范围、低成本 | 大量用户、简单需求统计 |
| 情景分析法 | 模拟多种未来场景推演 | 多场景、假设分析 | 长期规划、风险预判 |
| 专家判断法 | 单个/少数专家直接经验判断 | 经验、快速 | 紧急估算、小范围决策 |
德尔菲法 ✅ 优点：匿名、杜绝权威压制、结果客观 ❌ 缺点：慢、周期长、成本高 👉 不能开会讨论、全程书面多轮
头脑风暴 ✅ 自由发言、追求数量、禁止批评 👉 重在创意产出
名义小组 介于两者之间： 先各自写想法 → 再讨论 → 投票，兼顾公平与效率
- 要客观、防大佬压人 → 德尔菲
- 要脑洞、想点子 → 头脑风暴
- 要集体投票选方案 → 名义小组
- 要深入问用户 → 访谈
- 要大面积普查 → 问卷
7.需求获取 / 需求分析 / 需求验证
三者阶段+作用极简表格，软考直接背
| 需求获取 | 从用户、客户收集原始需求 | 听用户想要什么 | 访谈、问卷、观察、头脑风暴、JRP联合获取、原型、德尔菲 |
| 需求分析 | 整理、拆解、去重、矛盾处理、建模 | 把乱七八糟的需求变规范 | 结构化分析、面向对象分析、UML建模、数据流图 |
| 需求验证 | 评审、确认、签字，确保需求正确可实现 | 检查需求有没有问题 | 需求评审、原型确认、测试用例复核 |
8.发明专利 vs 实用新型专利
| 保护对象 | 产品、方法及其改进 | 产品的形状、构造及其改进 |
| 创造性要求 | 突出的实质性特点和显著进步 | 实质性特点和进步（门槛低） |
| 审查流程 | 初步审查 + 实质审查 | 仅初步审查 |
| 保护期限 | 20年 | 10年 |
| 权利稳定性 | 高（经过实质审查） | 较低（仅形式审查） |
发明要实质审查，保护期20年，创新要求显著进步； 实用新型只初审，保护期10年，创新要求普通进步。
9.未提交读 > 提交读 > 可重复读 > 串行化
从低到高排序：
- A. 串行化：隔离级别最高，性能最低，不选。
- B. 可重复读：隔离级别中等，性能中等，不选。
- C. 未提交读：隔离级别最低，性能最高，是正确答案。
- D. 提交读：隔离级别中等偏低，性能低于未提交读，不选。
💡 秒杀口诀： 性能从高到低：未提交读 > 提交读 > 可重复读 > 串行化 一致性从低到高：未提交读 < 提交读 < 可重复读 < 串行化
10. 数据库事务三大问题 + 隔离级别 终极速记表
三大问题 + 对应隔离级别（必背）
| 丢失修改 | 两个事务同时改同一数据，后改的覆盖先改的 | A 改了数据，B 也改，A 的修改直接没了 | 提交读（Read Committed）及以上 |
| 脏读（Dirty Read） | 读取了其他事务未提交的数据 | 读了别人改了但没提交的数据，对方回滚了，数据就“脏”了 | 提交读（Read Committed）及以上 |
| 不可重复读（Non-Repeatable Read） | 同一事务内，两次读取同一行数据，结果不一样 | 同一行数据，前后读两次，中间被别人改了，结果不一致 | 可重复读（Repeatable Read）及以上 |
| 幻读（Phantom Read） | 同一事务内，两次范围查询，结果集数量不一样 | 同一条件，前后查两次，中间被别人新增/删除了行，感觉像“幻觉” | 串行化（Serializable） |
- 脏读：读了未提交 → 解决：提交读
- 不可重复读：同一行，前后变 → 解决：可重复读
- 幻读：范围查，数量变 → 解决：串行化
| 未提交读 | ❌ 可能 | ❌ 可能 | ❌ 可能 | ❌ 可能 | 最高 |
| 提交读 | ✅ 解决 | ✅ 解决 | ❌ 可能 | ❌ 可能 | 较高 |
| 可重复读 | ✅ 解决 | ✅ 解决 | ✅ 解决 | ❌ 可能 | 中等 |
| 串行化 | ✅ 解决 | ✅ 解决 | ✅ 解决 | ✅ 解决 | 最低 |
11.防火墙全分类（按工作层级/实现方式）
| 包过滤防火墙 | 网络层（第3层） | 检查IP包头（源/目的IP、协议、端口） | 速度快、配置简单，安全性一般 |
| 状态检测防火墙（动态包过滤） | 网络层+传输层（3-4层） | 跟踪TCP会话状态，只放行合法响应包 | 比包过滤更安全，是目前主流 |
| 电路级网关防火墙 | 传输层（第4层） | 建立TCP连接代理，不解析应用数据 | 会话级过滤，无法防应用层攻击 |
| 应用层网关防火墙（代理防火墙） | 应用层（第7层） | 代理所有应用流量，解析协议内容 | 安全性高，但速度慢 |
| Web应用防火墙（WAF） | 应用层（第7层） | 专门防护HTTP/HTTPS，识别SQL注入、XSS等 | 针对Web应用，防护精准 |
| 下一代防火墙（NGFW） | 多层（3-7层） | 集成包过滤、状态检测、应用识别、入侵防御 | 一体化安全，功能最全 |
12.软件需求编写避坑清单（核心版）
| 可验证性 | 能通过客观测试判断是否达标 | 避免“美观、好用”这类主观描述，是本题的核心考点 |
| 无歧义性 | 所有干系人对需求的理解完全一致 | 避免“用户可以快速操作”这类模糊表述 |
| 完整性 | 覆盖所有业务场景，无遗漏、无缺失 | 避免“系统支持用户登录”但未说明异常场景 |
| 一致性 | 需求之间不矛盾，与整体业务逻辑对齐 | 避免“系统支持手机号登录”和“仅支持邮箱登录”同时存在 |
| 必要性 | 每个需求都对应明确的业务价值 | 剔除“为了好看加个动画”这类无意义的伪需求 |
| 可行性 | 技术、成本、时间上可落地实现 | 避免“系统支持1000万用户同时在线”但服务器配置不足 |
| 可追踪性 | 需求可追溯到业务目标、设计、测试用例 | 方便后期变更管理和问题排查 |
| 稳定性 | 需求在项目周期内不易频繁变更 | 避免把“临时想法”写入正式需求文档 |
13 系统分析阶段主要产出系统需求规格说明书
系统分析阶段的核心产出就是系统需求规格说明书（SRS, System Requirements Specification），它是整个项目后续设计、开发、测试的“基准文件”。
用户需求调研 → 业务流程梳理 → 数据/功能分析 → 系统需求规格说明书(SRS)
📋 一份标准SRS必须包含的核心内容
| 1. 引言 | 项目背景、目标、范围、术语定义 | – |
| 2. 总体描述 | 产品视角、用户特征、运行环境、约束条件 | – |
| 3. 功能需求 | 业务功能清单、用例说明、业务流程 | 对应数据动态分析（数据流转、业务场景） |
| 4. 数据需求 | 数据字典、实体关系（ER图）、数据约束 | 对应数据静态分析（数据结构、数据关系） |
| 5. 非功能需求 | 性能、安全性、可靠性、易用性、可维护性 | 对应“可验证性”考点，避免“界面美观”这类模糊描述 |
| 6. 其他需求 | 接口需求、合规需求、文档需求 | – |
⚠️ SRS的核心质量要求（高频考点） 一份合格的SRS，必须满足以下特性，这也是考试中常考的“需求质量标准”：
- ✅ 无歧义性：所有描述清晰唯一，不存在多种理解方式
- ✅ 可验证性：每个需求都能写出对应的测试用例（比如“响应时间≤2秒”，而非“响应要快”）
- ✅ 完整性：覆盖所有业务场景，无遗漏的功能/异常分支
- ✅ 一致性：需求之间无矛盾，前后逻辑统一
- ✅ 可修改性：结构清晰，方便后续变更维护
- ✅ 可追踪性：每个需求都能追溯到业务目标、测试用例
14.BAM
TFD、BAM 本质：都是「业务流程图」 只是层级、粒度、用途不一样。
一、BAM 是什么 BAM（Business Activity Mapping，业务活动模型/业务活动图示） 是结构化的业务流程建模工具，用于清晰、完整地描述一个业务内部“做什么、由谁做、输入输出是什么、按什么逻辑做”，侧重活动内部细节与逻辑，是系统分析与流程优化的核心工具（常见于软考系统分析师、SSADM 方法）。
二、核心定位与特点
- 与 TFD（业务流程图）区别
- TFD：看全局、跨部门流转、协作关系（城市交通路网图）。
- BAM：看局部、单个活动内部、操作细节（施工详图）。
- 核心特点
- 全面性：覆盖活动、角色、输入/输出、规则、资源、指标。
- 逻辑性：明确顺序、并行、分支（判断）等控制流。
- 可落地：直接支撑现状（As-Is）分析、未来（To-Be）设计、系统功能设计。
三、BAM 的核心要素（必考） 一个标准 BAM 包含 6 大要素：
| 活动（Activity） | 流程中的具体任务/步骤（节点），如“审核订单” |
| 流向（Flow） | 活动间的逻辑关系：顺序、并行、选择（分支）、循环 |
| 执行者（Role） | 岗位/角色/部门，如“财务专员”“系统” |
| 输入（Input） | 启动活动所需表单、数据、物料，如“订单申请表” |
| 输出（Output） | 活动产生的结果/文档/数据，如“审核通过单” |
| 资源/规则 | 依赖系统、表单、业务规则（如“金额>1万需经理审批”） |
四、BAM 的 5 类活动视角（CATWOE 延伸） 从 stakeholder 视角划分活动类型，用于高层建模：
五、BAM 的应用场景（软考高频）
六、BAM 示例（简化） 场景：客户订单审核流程
- 活动：接收订单 → 校验库存 → 金额审核 → 审批通过/驳回
- 执行者：客服、系统、财务专员、部门经理
- 输入：客户订单、库存数据
- 输出：审核通过单/驳回通知
- 规则：金额＞10000元需经理审批；库存不足直接驳回
七、BAM 与其他模型对比
| BAM | 活动内部细节、逻辑、权责 | 细 | 流程优化、系统设计 |
| TFD | 跨部门流转、协作关系 | 中 | 现状梳理、部门协同 |
| UML 活动图 | 系统流程、控制流、数据流 | 细 | 软件设计、开发 |
| DFD | 数据流动、加工、存储 | 细 | 数据建模、数据库设计 |
八、总结 BAM 是业务的“解剖图”：既看整体流程骨架，更看每个活动的执行细节、权责与规则，是从业务到系统设计的桥梁，核心价值在于精准描述、清晰分析、高效优化业务流程。
