一、软件过程模型（核心高频考点）
1. 瀑布模型
- 知识点：严格分阶段（需求→设计→编码→测试→维护），前一阶段输出是后一阶段输入，阶段间因果紧密，适合需求明确且稳定的项目。
- 缺点：需求完整性难确定，严格串行化，后期修改成本高。
- 实际场景：传统硬件开发（如嵌入式系统），需求明确且变更少。
- 重点：瀑布模型的特点、缺点及适用场景。
2. 原型模型
- 知识点：分两阶段（原型开发→目标开发），通过快速构建原型让用户反馈，解决需求不明确问题。
- 分类：快速原型（探索需求）、演化原型（逐步完善）。
- 实际场景：APP开发初期，用低保真原型确认用户交互逻辑。
- 重点：原型模型的阶段划分及适用场景。
3. 螺旋模型
- 知识点：结合瀑布与原型，引入风险分析（目标设定→风险分析→开发→评审），适合复杂高风险项目。
- 特点：通过多次迭代降低风险，每轮迭代生成可运行原型。
- 实际场景：大型软件项目（如操作系统开发），需持续评估技术风险。
- 重点：螺旋模型的核心（风险分析）及阶段构成。
4. V模型与W模型
- V模型：测试阶段与开发阶段一一对应（需求分析→验收测试，概要设计→系统测试），强调测试计划提前。
- W模型：开发与测试并行（需求分析→验收测试设计，概要设计→集成测试设计），更早介入测试。
- 实际场景：对质量要求高的项目（如医疗软件），需严格测试流程。
- 重点：V模型/W模型的对应关系及核心思想（测试阶段提前）。
5. 敏捷开发方法
- 知识点：以人为本、迭代增量、适应变化，适合需求变化快的小型项目。
- 核心原则（敏捷宣言）：个体交互>过程工具，可工作软件>大量文档，客户合作>合同谈判，响应变化>遵循计划。
- 常见框架：
- XP（极限编程）：强调测试驱动开发、结对编程、持续集成。
- Scrum：通过产品待办列表、迭代计划会议、每日站会管理项目，每次迭代1-4周，产出可发布增量。
- 实际场景：互联网产品开发（如微信小程序迭代），需快速响应用户需求。
- 重点：敏捷方法的核心原则、适用场景及典型框架（XP/Scrum）的特点。
二、基于构件的软件工程（CBSE）
- 知识点：通过复用现有构件（如Java类库、第三方组件）快速组装系统，遵循“购买而非重构”哲学。
- 构件特征：可组装性（公开接口）、可部署性（二进制形式）、文档化、独立性、标准化（如J2EE、CORBA）。
- 组装方式：顺序组装（按流程调用）、层次组装（接口兼容）、叠加组装（合并功能）。
- 实际场景：企业信息系统开发（复用财务、用户管理构件），降低开发成本。
- 重点：构件的核心特征（可组装性、可部署性）及组装方式。
三、需求工程（核心知识模块）
1. 需求开发与管理
- 需求开发阶段：
- 需求获取：通过用户面谈、问卷调查、头脑风暴等收集用户需求（如“用户希望系统支持扫码登录”）。
- 需求分析：将模糊需求转化为明确规格，用DFD（功能模型）、ER图（数据模型）、状态图（行为模型）建模。
- 需求确认：形成《需求规格说明书（SRS）》，经评审后成为需求基线。
- 需求管理：对需求基线进行变更控制（如CCB审批流程）、版本控制、需求跟踪（正向/反向跟踪需求关联）。
- 实际场景：开发电商系统时，通过JRP（联合需求计划会议）协调多方（运营、技术、用户）明确订单处理需求。
- 重点：需求开发的阶段划分、需求管理的核心活动（变更控制、需求跟踪）。
2. UML建模工具
- 静态图：类图（描述类与接口关系）、对象图、构件图；
- 动态图：用例图（用户与系统交互）、顺序图（时间顺序交互）、状态图（状态转换）、活动图（流程逻辑）。
- 实际场景：用用例图描述“用户下单”流程，包含“选择商品”“支付”“生成订单”等用例。
- 重点：UML图的分类（静态图/动态图）及典型图的作用（用例图、类图、顺序图）。
四、系统设计
1. 界面设计黄金三法则
- 用户控制：允许撤销操作（如删除文件的“撤销”按钮）；
- 减少记忆负担：使用默认值（如注册表单自动填充国家代码）；
- 一致性：统一按钮样式（如所有“提交”按钮均为蓝色）。
- 重点：界面设计的三大原则及其具体体现。
2. 结构化设计（模块独立性）
- 内聚：模块功能集中度，从低到高：偶然内聚→逻辑内聚→时间内聚→过程内聚→通信内聚→顺序内聚→功能内聚（最高）。
- 耦合：模块间依赖程度，从低到高：非直接耦合→数据耦合→标记耦合→控制耦合→外部耦合→公共耦合→内容耦合（最高）。
- 设计原则：高内聚（模块功能单一）、低耦合（模块交互简单）。
- 实际场景：设计电商系统时，将“用户登录”与“订单处理”分为独立模块，通过数据耦合传递用户ID。
- 重点：内聚与耦合的分类（从低到高）及设计原则（高内聚低耦合）。
3. 面向对象设计原则
- 单一职责原则：一个类只负责一个功能（如“用户类”只处理用户信息，不涉及订单逻辑）；
- 开放-封闭原则：对扩展开放（新增功能通过子类实现），对修改封闭（不修改已有代码）；
- 里氏替换原则：子类可替换父类（如“猫”是“动物”的子类，可在需要“动物”的地方使用“猫”）。
- 重点：面向对象设计的七大原则（尤其单一职责、开放-封闭、里氏替换）。
五、软件测试
1. 测试方法分类
- 动态测试：运行程序找错，如黑盒测试（等价类划分、边界值分析）、白盒测试（逻辑覆盖、路径测试）。
- 静态测试：不运行程序，如代码审查、桌面检查，关注代码结构（如未使用的变量、语法错误）。
- 实际场景：用边界值分析测试“年龄输入框（1-100岁）”，测试数据取0、1、100、101，验证边界处理。
- 重点：动态测试与静态测试的区别，黑盒/白盒测试的具体技术（等价类、边界值、逻辑覆盖）。
2. 测试阶段
- 单元测试：测试单个模块（如函数），依据详细设计文档，需驱动模块（调用被测模块）和桩模块（模拟被调用模块）。
- 集成测试：测试模块间接口，分自顶向下（先测顶层模块，用桩模块模拟下层）和自底向上（先测底层模块，用驱动模块调用）。
- 系统测试：测试整个系统，依据需求文档，包括功能测试、性能测试（压力测试、负载测试）、安全性测试。
- 实际场景：微信登录功能，单元测试验证“密码加密”函数，集成测试验证“登录模块”与“用户数据库”交互，系统测试验证并发登录性能。
- 重点：测试阶段的划分（单元/集成/系统/确认测试）及各阶段依据和目标。
六、软件维护
1. 维护类型
- 正确性维护：修复上线后的BUG（如支付时金额计算错误）；
- 适应性维护：适应环境变化（如系统从Windows迁移到Linux）；
- 完善性维护：增加新功能（如电商系统新增“直播购物”模块）；
- 预防性维护：提前优化代码，为未来做准备（如将单体架构重构为微服务）。
- 重点：维护类型的定义及典型场景（正确性、适应性、完善性维护）。
2. 遗留系统演化策略
- 淘汰：技术落后且无价值（如早期DOS系统）；
- 继承：技术落后但仍需使用（如银行旧核心系统）；
- 改造：提升技术或功能（如将单体应用拆分为微服务）；
- 集成：解决“信息孤岛”（如不同部门系统数据互通）。
- 实际场景：企业遗留的ERP系统技术老旧但业务价值高，可通过“改造”升级架构。
- 重点：遗留系统策略的选择（淘汰/继承/改造/集成）。
总结（高频考点速记）
- 过程模型：瀑布（需求明确）、螺旋（风险分析）、敏捷（快速迭代）、V/W模型（测试对应关系）。
- 需求工程：需求开发阶段（获取→分析→确认）、需求管理（变更控制）、UML图分类。
- 设计原则：高内聚低耦合、面向对象七大原则（单一职责、开放封闭）。
- 测试技术：黑盒（等价类、边界值）、白盒（逻辑覆盖）、测试阶段划分。
- 维护类型：正确性（修BUG）、完善性（加功能）、适应性（环境变化）。
