第一关 · 软件工程基础
总时长：48 小时 | 目标：解决"如何系统化地开发和维护软件？" 考试映射：综合知识 10-15 题 | 案例分析：需求分析题、开发流程设计题 | 论文：《论软件需求管理》《论软件开发模型的选择与应用》
Step 1：本关资料（海量输入）
| 资料类型 | 具体资料 | 用途 | |---------|---------|------| | 教材 | 《架构师教程》第 1-3 章（软件工程概述、需求工程、设计方法） | 建立知识框架，理解基本概念 | | 真题 | 2020-2025 综合知识·软件工程部分（约 40 题） | 锁定高频考点，掌握出题风格 | | 论文参考 | 2021 下《论软件维护方法及其应用》真题范文 | 学习论文中软件工程理论的展开方式 | | 补充 | AIoT 项目需求文档 / SRS 模板 | 结合实际项目理解理论 |
精准阅读策略：
- 先通读教材章节，建立知识树（不用背细节）
- 做一遍近 5 年真题，标记错题对应的知识点
- 回到教材精读错题涉及的段落
Step 2：本关心智模型
模型 1：软件开发生命周期（SDLC）——"软件是有生命的东西"
- 核心思想：软件开发不是"写代码"，是一个从需求→设计→实现→测试→维护的完整生命周期。就像盖房子：先画图纸（设计），再施工（编码），再验收（测试），还要住进去修修补补（维护）。
- 关键变量：需求变更频率、项目规模、交付压力、团队能力
- 应用场景：选择开发模型时——需求稳定用瀑布，需求多变用敏捷，追求持续交付用 DevOps
- 局限性：SDLC 是理想化的线性模型，实际项目经常迭代和回溯
- 考试映射：每年必考开发模型对比题（瀑布/迭代/敏捷/DevOps），综合知识 2-3 题
模型 2：需求工程漏斗——"需求是漏斗的入口，出口决定了系统上限"
- 核心思想：搞不清楚用户要什么，后面做什么都白搭。需求获取→分析→规格化→验证→管理，每一步都在过滤和精确化需求，就像漏斗一样越往下越精确。
- 关键变量：功能需求 vs 非功能需求、需求优先级、需求变更控制（变更控制委员会 CCB）
- 应用场景：案例题给一堆需求让你分类（功能/非功能），论文写"需求管理实践"
- 局限性：需求工程无法预知用户尚未意识到的需求，需要通过原型和迭代来发现
- 考试映射：综合知识 3-4 题，案例分析 1-2 题（需求分类、需求变更管理）
模型 3：SOLID 五原则——"让代码好改、好测、好维护的五条军规"
- 核心思想：SOLID 是面向对象设计的五项基本原则，本质是控制"变化的影响范围"——一个地方变了，其他地方尽量不受影响。
- S 单一职责：一个类只做一件事
- O 开闭原则：对扩展开放，对修改关闭
- L 里氏替换：子类能替换父类
- I 接口隔离：接口要小而专
- D 依赖倒置：依赖抽象不依赖具体
- 关键变量：类的职责数量、继承层次深度、接口粒度
- 应用场景：架构设计中评估代码质量，案例分析中判断设计方案优劣
- 局限性：SOLID 是原则不是教条，过度应用会导致过度设计（如为了单一职责拆出太多小类）
- 考试映射：综合知识 1-2 题，案例分析中设计模式的选择依据
Step 3：本关分歧点
分歧点 1：瀑布 vs 敏捷——"计划驱动"还是"价值驱动"？
| 维度 | A 方：瀑布模型 | B 方：敏捷开发 | |------|---------------|--------------| | 核心信念 | 需求是可预测的，前期规划好后面就稳 | 需求是不可预测的，拥抱变化持续调整 | | 优势 | 文档完整、进度可控、适合大型团队 | 快速交付价值、灵活响应变化、客户满意度高 | | 劣势 | 需求变更代价极高、反馈周期长 | 文档不完整、难以估算最终成本 | | 适用 | 需求稳定、合规要求高（银行、航天） | 需求多变、创新产品（互联网、SaaS） |
考试倾向：近年考试偏重敏捷/DevOps，但不会直接说"瀑布不好"。通常以"某公司项目需求频繁变化，应该采用什么模型"的形式出现，答案选敏捷。
为什么重要：选错开发模型 = 项目失败的第一步。架构师必须能根据项目特征选择合适的模型。
分歧点 2：功能需求 vs 非功能需求——"做什么"还是"做得怎样"？
| 维度 | A 方：功能需求优先 | B 方：非功能需求优先 | |------|-------------------|-------------------| | 核心信念 | 用户要的是功能，先把功能做出来 | 功能有了但系统慢、不安全、不可用，等于没做 | | 典型错误 | 只关注功能列表，忽略性能、安全、可用性 | 过度设计非功能属性，导致开发周期过长 | | 考试表现 | 题目给一堆需求让你分类，经常把质量属性（非功能）错分成功能需求 |
考试倾向：质量属性归属题几乎每年必考，见 03 关。功能需求 = 系统应该"做什么"；非功能需求 = 系统"做得怎样"（性能、安全、可用性等）。
为什么重要：架构师的核心工作就是处理非功能需求（质量属性），这是架构评估的基础。
分歧点 3：CMMI 级别——"过程成熟度"到底值不值得投入？
| 维度 | A 方：重视过程改进 | B 方：够用就好 | |------|-------------------|--------------| | 核心信念 | 成熟的过程是质量的保证 | 过程是手段不是目的，过度过程化反而降低效率 | | 考试重点 | CMMI 5 个等级定义（初始→已管理→已定义→量化管理→优化） | — | | 考试陷阱 | CMMI 3 级 = 已定义级（组织级过程已定义），不是"可重复"（2 级） | — |
考试倾向：CMMI 级别定义是选择题常客，记住"初始→已管理→已定义→量化管理→优化"对应 1-5 级。
Step 4：闯关任务（动手验证）
任务 1：开发模型对比分析（2h）
结合你的 AIoT 项目：
- 列出瀑布、迭代/增量、敏捷（Scrum）、DevOps 四种模型的适用条件
- 分析你的 AIoT 项目适合哪种模型，为什么
- 写出 300 字的分析报告
任务 2：编写简化版 SRS（3h）
- 用标准 SRS 模板为 AIoT 项目写一份简化需求规格说明书
- 明确标注每条需求是功能需求还是非功能需求
- 识别至少 3 条可能的需求变更场景，说明如何管理
任务 3：SOLID 原则落地验证（2h）
- 在你的 AIoT 项目代码中找 3 个违反 SOLID 的例子
- 说明违反了哪个原则、为什么违反
- 给出重构方案（伪代码或设计图）
Step 4.5：💬 AI 教练对话
使用时机：遇到概念不理解、做错题需要分析、写论文需要素材时
Theory Agent —— 深入理解概念
我正在备考软考高级架构师，正在学习"软件工程基础"。
请用以下方式帮我理解 [具体概念]：
1. 先用一句话概括本质（费曼风格）
2. 再列出考试常考的 3 个要点
3. 最后给出一个真实项目中的例子
注意：不要给我教材定义，我要理解"为什么需要这个东西"。
Review Agent —— 审查你的输出
这是我的需求分析/开发模型选择，请帮我审查：
1. 有没有遗漏的关键需求？
2. 开发模型的选择是否合理？为什么？
3. 如果考试中遇到类似案例题，我的回答还缺什么？
Reality Agent —— 案例题实战
我在软考案例题中遇到这种情况：[描述场景]。
请帮我分析：
1. 应该用什么软件工程理论来解答？
2. 实际项目中，架构师会怎么处理？
3. 考试答题的标准结构是什么？
Step 5：关 AI 自测
⚠️ 关闭 AI，独立完成后再对照答案
自测题 1（综合知识风格）
软件开发过程中，需求变更管理通常由哪个组织/角色负责审批？
A. 项目经理单独决定 B. 变更控制委员会（CCB） C. 开发团队集体投票 D. 客户代表
点击查看答案
答案：B. 变更控制委员会（CCB）
变更控制委员会（Change Control Board）由项目相关方代表组成，负责评估、审批或否决变更请求。项目经理、开发团队或客户单独决定都不符合规范流程。
自测题 2（案例分析风格）
某公司正在开发一个在线教育平台，项目初期需求明确但中期频繁变更，团队有 8 人，产品经理要求每 2 周交付可演示版本。请回答：
(1) 推荐采用什么开发模型？为什么？ (2) 需求变更频繁可能带来什么风险？如何缓解？
点击查看答案
(1) 推荐采用敏捷开发模型（Scrum）。
原因：
- 需求中期频繁变更 → 瀑布模型不适用（变更代价太高）
- 每 2 周交付可演示版本 → 符合 Scrum 的 Sprint 迭代周期
- 8 人团队规模适中，适合 Scrum 的标准团队配置
(2) 风险及缓解措施：
| 风险 | 缓解措施 | |------|---------| | 需求蔓延（范围失控） | 建立 Product Backlog 优先级排序，每个 Sprint 严格控制范围 | | 技术债务积累 | 每个 Sprint 预留 20% 时间处理技术债务 | | 团队疲劳（频繁变更导致士气低落） | 通过 Sprint 回顾会持续改进流程 | | 架构设计缺乏前瞻性 | 在前几个 Sprint 中投入时间做架构 Spike（技术探索） |
自测题 3（综合知识风格）
以下关于 CMMI 的说法，正确的是？
A. CMMI 2 级称为"已定义级" B. CMMI 3 级称为"量化管理级" C. CMMI 4 级过程是已量化管理的 D. CMMI 5 级称为"已管理级"
点击查看答案
答案：C. CMMI 4 级过程是已量化管理的
CMMI 五个等级：
- 初始级（Initial）— 过程不可预测
- 已管理级（Managed）— 项目级过程已计划执行
- 已定义级（Defined）— 组织级过程已标准化
- 量化管理级（Quantitatively Managed）— 过程用统计方法控制
- 优化级（Optimizing）— 持续改进
A 错（2 级是已管理级），B 错（3 级是已定义级），D 错（5 级是优化级）。
自测题 4（论文素材检验）
请用 3 句话概括"开闭原则"的核心思想，并结合 AIoT 设备接入服务举一个例子。
点击查看答案
开闭原则核心：对扩展开放，对修改关闭——新增功能时不应该修改已有代码，而是通过扩展来添加新功能。
AIoT 例子：设备接入服务支持 MQTT 协议，后续需要新增 HTTP 协议支持。按照开闭原则，不应该修改原有 MQTT 接入代码，而是定义一个统一的 DeviceConnector 接口，新增 HttpConnector 实现类来支持 HTTP 协议，通过工厂模式根据设备类型选择对应的 Connector。这样原有 MQTT 代码不受影响，扩展新协议只需添加新类。
Step 6：费曼输出 + 信心校准
一句话版本
软件工程 = 把"用户要什么"（需求）变成"系统能用"（交付）的系统化方法，核心是选对开发模型、管好需求变更、遵循设计原则。
三分钟版本
（对着镜子或录音讲 3 分钟，不看书）
软件工程解决的核心问题是：如何系统化地开发和维护软件。
第一个关键概念是开发模型。瀑布模型适合需求稳定的场景，但现实世界中需求经常变，所以敏捷开发更受欢迎——它通过短周期迭代（2-4 周一个 Sprint）持续交付价值，拥抱变化。
第二个关键概念是需求工程。需求分为功能需求（系统做什么）和非功能需求（系统做得怎样，如性能、安全、可用性）。需求管理的核心是控制变更——不是拒绝变更，而是有序地评估和批准变更。
第三个关键概念是 SOLID 设计原则。其中最重要的是开闭原则——对扩展开放、对修改关闭，这意味着我们应该通过添加新代码来增加功能，而不是修改已有代码。
考试中，这三个知识点分别对应：开发模型选择题（每年 2-3 题）、需求分类/变更管理题（每年 3-4 题）、设计模式/架构设计题。
信心自评
| 知识点 | 信心 1-5 | 能否给别人讲清楚？ | 需要复习？ | |--------|---------|------------------|-----------| | 开发模型对比（瀑布/敏捷/DevOps） | /5 | □ 能 □ 不能 | □ 需要 | | 需求工程五步骤 | /5 | □ 能 □ 不能 | □ 需要 | | 功能需求 vs 非功能需求分类 | /5 | □ 能 □ 不能 | □ 需要 | | SOLID 五原则 | /5 | □ 能 □ 不能 | □ 需要 | | CMMI 五个等级 | /5 | □ 能 □ 不能 | □ 需要 | | 软件维护四种类型 | /5 | □ 能 □ 不能 | □ 需要 |
📌 常见误区
- "瀑布模型已经过时了" → 错！银行、航天等合规场景仍然用瀑布，考试不会说它"过时"
- "非功能需求就是性能" → 错！非功能需求包括性能、安全性、可用性、可修改性、可测试性等多个维度（见 03 关）
- "敏捷 = 没有文档" → 错！敏捷不是不要文档，是"够用就好"的文档
- "CMMI 1 级 = 没有过程" → 对！初始级就是"想到什么做什么"
🔧 工程映射
- 架构师日常工作：需求评审（需求工程）→ 架构设计（SOLID）→ 技术选型（开发模型影响）
- DevOps 实践：CI/CD = 持续集成/持续部署，是敏捷开发的工程化延伸
- 项目管理：敏捷中的 Scrum Master = 项目推进者，Product Owner = 需求负责人
✅ 通关标准
- [ ] 信心自评所有知识点 ≥ 4/5
- [ ] 三分钟版本能脱稿讲完
- [ ] 自测题正确率 ≥ 75%
- [ ] 完成 SRS 写作练习
- [ ] 真题正确率 ≥ 80%
- [ ] 结合 AIoT 项目写出开发模型分析报告