软考高级系统架构设计师备考，写着方便自己看，如果有发现不对或少得的地方可以多多指正，谢谢各位兄弟。
一、软件工程基础概念
1. 软件工程定义
应用计算机、数学、管理科学原理，用工程化方法解决软件问题，目标是提效、提质、降本。
例子：电商系统开发不是随意堆代码，而是按「需求调研→设计→编码→测试→上线」的工程流程推进，避免后期大规模返工。
2. 软件生命周期
分3个阶段：
软件定义期：可行性研究+需求分析，确定项目总目标
软件开发期：概要设计→详细设计→编码→测试，实现系统功能
运行维护期：系统上线后交付用户使用，持续迭代优化
例子：做校园二手交易小程序，前期调研「能不能做、要做哪些功能」是定义期；画原型、写代码、测bug是开发期；上线后修复闪退、加「校园配送」功能是运行维护期。
3. 软件文档分类
用户文档：描述系统功能和使用方法，不关心实现逻辑，比如APP操作指南、用户手册
系统文档：描述系统设计、实现、测试细节，比如数据库设计文档、接口说明文档
4. 软件工程PDCA过程
P（Plan，规格说明）：编写《需求规格说明书》，明确系统功能、运行限制
D（Do，软件开发）：按规格说明落地代码实现
C（Check，软件确认）：验证开发成果是否满足用户需求，比如用户试用、功能测试
A（Action，软件演进）：运行中根据用户新需求迭代优化，比如给二手交易小程序加「担保交易」功能
5. 软件设计四活动
数据设计：设计用户表、商品表的字段结构
软件结构设计：拆分系统为前端页面、后端接口、数据库等独立模块
人机界面设计：设计小程序发布页的按钮位置、配色、交互逻辑
过程设计：设计「下单后库存自动扣减」的业务流转逻辑
6. 软件工具分类
类别 | 工具举例 |
|---|---|
开发工具 | Axure（需求分析）、IDEA（编码）、JUnit（单元测试） |
维护工具 | Git（版本控制）、JD-GUI（逆向工程） |
管理工具 | Jira（项目管理）、SonarQube（代码质量检测） |
二、经典软件过程模型（高频考点）
1. 瀑布模型
特点：文档驱动、线性流程，需求必须完全明确才能启动。
优缺点：阶段清晰、易管控，但需求变更成本极高，错误要到后期才会暴露。
适用场景：银行核心交易系统等需求极度稳定的项目。
反例：做到一半客户突然要求加「数字人民币转账」功能，需要从头修改所有设计文档，成本极高。
2. 原型模型
特点：快速构建简易原型，收集用户反馈逐步明确需求，适合需求不明确的场景。
例子：客户要做全新的元宇宙社交APP，自己也说不清功能细节，先做个「捏脸+聊天」的简易原型给用户试用，再根据反馈调整需求。
3. 螺旋模型
特点：瀑布模型+原型模型的结合，加入风险分析环节，每个周期分「目标设定→风险分析→开发验证→评审」4步。
适用场景：航天控制系统等庞大、复杂、高风险的系统，每一步都要排查算法可靠性，避免上线后才发现致命问题。
4. 增量模型
特点：分批次交付可独立运行的版本，比瀑布模型更早让用户获得价值。
例子：做企业ERP系统，第一个增量先做财务模块，上线给财务部门使用；第二个增量做供应链模块，对接财务模块；第三个增量做人力资源模块，逐步拼成完整ERP。
真题考点：增量模型每次交付的都是可独立运行的产品，原型仅用于演示，不具备生产能力。
5. 喷泉模型
特点：面向对象开发，迭代无间隙，各阶段无明显边界，开发团队可同步工作。
例子：游戏开发时，美术画角色原画的同时，程序写角色移动的基础代码，不用等原画全部完成再开工，大幅提升效率，但对文档管理要求极高。
6. 基于构件的开发模型
特点：复用预制的成熟构件，增强可靠性、降低成本。
例子：做电商系统不用自己开发支付功能，直接复用支付宝SDK；不用自己开发登录模块，复用微信开放平台登录组件，减少重复开发工作量。
三、敏捷开发与统一过程（RUP）
1. 敏捷开发核心
四大宣言：个体交互胜过过程和工具、可工作软件胜过详尽文档、客户合作胜过合同谈判、响应变化胜过遵循计划。
核心思想：适应型（拥抱变化）、以人为本、迭代增量开发。
例子：抖音每周发布一个小版本，根据用户反馈动态调整推荐算法，不用提前定死半年的功能计划。
2. 主流敏捷方法
极限编程（XP）：强调结对编程、持续集成，适合小团队做核心业务系统
Scrum：30天为一个「冲刺（Sprint）」，每天站会同步进度，比如做外卖APP，第一个冲刺做商家入驻功能，第二个冲刺做用户下单功能
特征驱动开发（FDD）：先构建整体对象模型，再按「客户信息管理」「销售线索跟进」等特征逐个开发
3. 统一过程（RUP）
二维模型：横向是9个核心工作流（业务建模、需求、分析设计、实现、测试、部署、配置变更管理、项目管理、环境），纵向是4个阶段：
初始阶段：定项目愿景和范围，比如「做一款面向中小微企业的报销系统」
细化阶段：确定系统架构（比如前后端分离架构）、制定开发计划和资源需求
构造阶段：编码、测试，逐步完成报销申请、审批、对账等功能
移交阶段：上线部署，给用户做操作培训
核心特点：用例驱动、以架构为中心、迭代增量。
真题考点：RUP的9个核心工作流不包含「成本管理」。
4+1视图示例：
用例视图（测试人员看功能覆盖）、逻辑视图（程序员看代码结构）
实现视图（运维看部署包结构）、进程视图（性能测试人员看并发能力）
部署视图（系统工程师看服务器拓扑）
四、能力成熟度模型（CMM/CMMI）
1. CMM五级成熟度
从低到高依次为：
初始级：过程混乱，靠个人能力，经常延期（比如小作坊写代码，想到哪写到哪）
已管理级：单个项目有规范的管控流程
已定义级：组织层面有统一开发标准，所有项目按标准执行
定量管理级：用历史数据量化管控，比如每个模块的开发时长误差不超过10%
优化级：持续优化流程，定期复盘项目问题并更新规范
2. CMMI两种表示方法
阶段式：和CMM一致，分5个成熟度等级
连续式：按过程域单独评级，比如配置管理达到4级，需求管理达到3级
五、逆向工程与软件复用
1. 软件复用
不止复用代码，还包括复用需求、设计、文档、体系结构等。
例子：阿里的「中台战略」，把用户、支付、物流等通用能力沉淀为中台，新业务直接复用，不用从零开发。
2. 逆向工程四级抽象（从低到高）
级别 | 描述 | 例子 |
|---|---|---|
实现级 | 抽象语法树、符号表等 | 拿到编译后的class文件，反编译得到代码结构 |
结构级 | 模块间的依赖关系 | 分析代码得到调用图，知道哪个函数调用了哪个函数 |
功能级 | 程序段的功能和关系 | 分析得到「下单→扣库存→支付」的数据流模型 |
领域级 | 代码与业务领域的对应关系 | 得到用户、订单、商品的E-R领域模型，抽象级别最高 |
真题考点：结构级反映模块间的依赖关系，功能级反映程序段的功能和关系。
3. 相关概念辨析
重构：同一抽象级别转换系统描述，比如把for循环改成Stream流写法，功能不变，仅优化实现形式
再工程：逆向工程+新需求开发+正向工程，比如把老的Struts2系统重构为Spring Boot系统，同时加微服务新功能
正向工程：基于逆向得到的设计文档修改系统，比如根据逆向得到的数据库设计，优化查询性能
六、需求工程
1. 需求三层结构
层级 | 描述 | 例子 |
|---|---|---|
业务需求 | 组织/客户的高层目标 | 老板要求「做一款提升销售效率的系统」 |
用户需求 | 用户的使用诉求 | 销售提出「要能一键导出客户跟进记录」 |
系统需求 | 开发需落地的具体功能 | 开发定义「系统需实现客户记录导出接口，支持Excel格式，单次最多导出1万条」 |
系统需求又分为：功能需求（导出功能）、非功能需求（导出响应时间≤3秒）、设计约束（必须使用公司统一的MySQL数据库）。
2. 需求获取方法
方法 | 适用场景 | 例子 |
|---|---|---|
用户面谈 | 需求复杂、用户少 | 找10个销售一对一聊，挖掘真实使用痛点 |
需求研讨会 | 快速对齐多方共识 | 把销售、产品、开发拉到一起，2天内对齐所有需求 |
问卷调查 | 用户量大、无法一一访谈 | 给1000个用户发问卷，统计最需要的TOP3功能 |
原型法 | 需求不明确 | 做低保真原型让用户点击，确认需求是否符合预期 |
JRP（联合需求计划） | 关键用户参与 | 组织关键用户、分析师、开发团队共同开会定需求 |
3. 需求变更管理
流程：问题分析→变更描述→变更分析和成本计算→变更实现
真题考点：变更由CCB（变更控制委员会）审批，CCB是决策机构，不直接参与开发；需求变更不是有利无弊，会带来额外的成本和风险。
例子：项目中期客户要求加报表功能，先评估需要多花5个人天、会影响现有进度，提交CCB审批通过后再安排开发，不能直接修改代码。
4. 需求跟踪
正向跟踪：检查SRS里的每个需求，是否都有对应的设计、代码、测试用例，避免漏做功能
反向跟踪：检查代码、测试用例是否能追溯到SRS里的需求，避免做无用功
例子：看到「导出客户记录」的代码，要确认SRS里有对应的需求；看到SRS里的「导出」需求，要确认有对应的测试用例覆盖。
七、结构化分析与设计
1. 核心思想
自顶向下、逐层分解，面向数据流。
2. 结构化分析工具
（1）数据流图（DFD）
4个基本元素：
外部实体：系统外的人员/组织，比如「考生」给考务系统提交报名单
加工：输入到输出的转换，比如「成绩统计」模块把答题卡数据转为成绩单
数据流：数据的流向，比如报名单从考生流向考务系统
数据存储：存储数据的介质，比如存储成绩的数据库
避坑：
「黑洞」：加工只有输入没有输出，比如成绩统计只有答题卡输入，没有成绩单输出
「奇迹」：加工只有输出没有输入，比如凭空生成成绩单
「灰洞」：输入不足以产生输出，比如只有考生ID就想生成完整成绩单，缺少考试数据
分层示例：顶层图只有一个「考务系统」的加工；0层图拆分为「报名管理」「成绩管理」「证书管理」三个加工；再往下每层拆分得更细。
（2）数据字典
给DFD中的元素做说明，比如：机票=姓名+日期+航班号+起点+终点+费用，起点=[北京|上海|广州]。
（3）加工逻辑描述
结构化语言：比如「如果订单金额>100元，则免运费」
判定表/判定树：比如不同会员等级的折扣规则：普通会员不打折，银卡95折，金卡9折，用表格或树形结构清晰展示。
3. 结构化设计
（1）核心原则：高内聚、低耦合
耦合（模块间依赖度）：从低到高为「非直接耦合→数据耦合→标记耦合→控制耦合→通信耦合→公共耦合→内容耦合」，内容耦合最差，严禁使用。
例子：数据耦合是模块A只给模块B传需要的用户ID，是最优的耦合方式；内容耦合是模块A直接修改模块B的局部变量，是最差的耦合方式。
内聚（模块内部关联度）：从高到低为「功能内聚→顺序内聚→通信内聚→过程内聚→时间内聚→逻辑内聚→偶然内聚」，功能内聚最优。
例子：功能内聚是模块只做「计算订单总价」一件事，内聚最高；偶然内聚是模块里既有计算价格的函数，又有发邮件的函数，完全无关，内聚最低。
真题考点：耦合设计原则是「尽量用数据耦合，少用控制耦合，限制公共耦合，禁用内容耦合」；高内聚的典型是功能内聚。
（2）设计工具
工具 | 特点 | 适用场景 |
|---|---|---|
程序流程图 | 直观易懂，但难描述数据结构 | 简单程序逻辑设计 |
N-S图（盒图） | 结构化强，适合简单程序 | 教学、简单模块设计 |
PAD图 | 体现自顶向下的设计过程 | 结构化程序设计 |
IPO图 | 描述模块的输入、处理、输出 | 单个模块的详细设计 |
HIPO图 | 层次图+IPO图，既看整体结构，又看模块细节 | 系统整体设计+模块详细设计 |
4. 结构化编程
只用「顺序、选择、循环」三种控制结构，一个入口一个出口，禁止使用goto语句跳转。
八、软件测试
1. 测试基本原则
尽早测试、持续测试
避免开发人员自己测试自己的代码
既要测试合理输入，也要测试不合理输入（比如登录功能要测试空密码、超长账号等场景）
严格按测试计划执行，妥善保存测试用例、测试报告
2. 测试方法
类型 | 特点 | 常用技术 |
|---|---|---|
静态测试 | 不运行程序，人工/工具检测 | 桌前检查、代码审查、代码走查，能发现30%-70%的错误 |
动态测试 | 运行程序检测 | 黑盒测试（功能测试，不看代码，比如测下单功能是否正常）、白盒测试（结构测试，看代码逻辑，比如覆盖所有if-else分支） |
真题考点：静态测试是不运行程序的检测，黑盒测试是功能测试，不考虑内部实现。
3. 测试阶段
阶段 | 测试对象 | 测试依据 | 特点 |
|---|---|---|---|
单元测试 | 单个模块 | 详细设计说明书 | 测模块内部逻辑和数据结构 |
集成测试 | 模块组合 | 概要设计文档 | 测模块间接口是否正确，比如下单后库存是否扣减 |
确认测试 | 完整系统 | 需求规格说明书 | Alpha测试（开发环境下用户测试，开发在场）、Beta测试（真实环境下用户测试，开发不在场）、验收测试（用户主导，是是否接收软件的核心依据） |
系统测试 | 完整集成系统 | 用户需求/开发合同 | 测功能、性能、压力、安全等，比如电商大促时能否扛住10万并发 |
回归测试 | 变更后的系统 | 变更需求 | 验证变更部分是否正确，同时确保原有功能没有被改坏 |
真题考点：系统测试依据是需求规格说明书；回归测试的目的是验证变更不影响原有功能。
九、调试、度量与维护
1. 调试
测试发现bug后，定位问题并修复，常用方法：
回溯法：从报错位置往回追溯代码，查找参数错误来源
原因排除法：列出所有可能的原因，逐一排查（演绎法、归纳法、二分法）
注意：谁开发的代码谁负责调试。
2. 软件度量：McCabe环路复杂度
基于程序控制流计算逻辑复杂度，公式：V(G)=E-N+2（E是边数，N是节点数），复杂度越高越难维护，一般超过10就需要重构。
例子：一个程序有10个节点、12条边，复杂度=12-10+2=4，需要至少4个测试用例覆盖所有路径。
真题考点：环路复杂度=封闭区域数+1，比如有3个封闭区域，复杂度为4。
3. 软件维护
（1）遗留系统演化策略
策略 | 适用场景 | 例子 |
|---|---|---|
淘汰 | 技术过时、业务价值低 | 老旧的单机版员工考勤系统，直接弃用 |
继承 | 技术过时、业务价值高 | 银行核心交易系统，暂时不动，周边对接新系统 |
集成 | 技术先进、业务价值低 | 某部门单独使用的报表系统，把数据接入新的大数据平台 |
改造 | 技术先进、业务价值高 | 老电商平台重构为微服务架构，提升性能 |
真题考点：技术含量高、业务价值低、仅能服务单个部门的遗留系统，采用集成策略。
（2）系统转换方法
方法 | 特点 | 适用场景 |
|---|---|---|
直接转换 | 直接停用旧系统启用新系统，成本低、风险高 | 小系统，比如部门内部通知系统 |
并行转换 | 新旧系统并行运行1-3个月，风险极低、成本高 | 大系统，比如银行核心交易系统 |
分段转换 | 分批次替换子系统，平衡成本和风险 | 超大系统，比如政务一体化平台，先上社保模块，再上医保模块 |
（3）维护类型（占比从高到低）
完善性维护（50%-60%）：扩充功能、改善性能，比如给电商系统加直播带货功能
适应性维护：适应环境变化，比如安卓14更新后，APP适配新的权限规则
正确性维护：修复测试阶段未发现的问题，比如修复支付失败的bug
预防性维护：为未来变化做准备，比如提前把系统从Java 8升级到Java 17，避免官方停止维护后出现问题
十、净室软件工程与基于构件的软件工程
1. 净室软件工程
核心思想是「第一次就把事情做对」，用数学和统计方法在设计阶段消除错误，理论上提倡不做单元测试，追求零缺陷。
适用场景：军工、航天等对可靠性要求极高的系统。
真题考点：净室软件工程不是真的不做模块测试，只是理论上提倡，实际落地仍需测试；理论基础是函数理论和抽样理论。
2. 基于构件的软件工程（CBSE）
核心是「购买而非重构」，用预制构件组装系统，构件需满足5个特征：可组装、可部署（二进制形式，无需编译）、文档化、独立、标准化。
（1）构件组装方式
顺序组装：上一个构件的输出是下一个的输入，比如先调用支付构件，再把支付结果传给订单构件
层次组装：一个构件调用另一个构件的服务，比如订单构件调用库存构件的扣减库存服务
叠加组装：多个构件合并成新构件，对外提供新接口，比如把用户、支付、订单构件合并成电商核心构件
真题考点：构件组装方式不包括循环组装。
（2）接口不兼容问题解决（通过适配器解决）
参数不兼容：接口操作名相同，但参数类型/个数不同，比如A构件要String类型的用户ID，B构件传的是Long类型，写适配器做类型转换
操作不兼容：接口操作名不同，比如A构件叫
getUser，B构件叫queryUser，适配器做名称映射操作不完备：一个构件的提供接口是另一个的子集，比如B构件有查询、新增、删除用户功能，A构件只有查询功能，适配器补全缺失的操作
真题考点：一个构件的提供接口是另一个构件请求接口的子集，属于操作不完备问题。
十一、软件项目管理
1. 4P管理
人员（Person）、产品（Product）、过程（Procedure）、项目（Project），是项目管理的核心要素。
2. 进度管理工具
工具 | 优点 | 缺点 |
|---|---|---|
甘特图 | 清晰展示任务的起止时间、并行情况 | 无法体现任务间的依赖关系，难以识别关键路径 |
PERT图 | 能识别关键路径、计算松弛时间 | 绘制复杂，不如甘特图直观 |
真题考点：
关键路径：从开始到结束的最长路径，总长度是项目最短工期，关键路径上的活动松弛时间为0，延期会直接影响项目总工期。
松弛时间=最迟开始时间-最早开始时间=关键路径总时间-包含该活动的最长路径总时间。
例子：某项目关键路径为ACFIJ，总长度58天，F→H在关键路径上，一旦延期就会影响整个项目进度。
3. 软件配置管理
核心是版本控制和变更控制：
基线：开发阶段的里程碑节点，比如需求基线评审通过后，后续修改需走正式变更流程
软件配置项（SCI）：配置管理的基本单位，包括代码、文档、配置文件等
4. 软件质量特性
可维护性：修改缺陷、增加功能、提升质量的难易程度
可测试性：验证软件正确性的难易程度
可扩展性：增加新功能的难易程度
可伸缩性：用户/数据量增长时，系统维持高服务质量的能力，比如电商大促时扩容服务器即可扛住流量
真题考点：定位修改点的难易程度是可维护性，用户量增加维持服务能力是可伸缩性。
5. 风险管理
风险识别：识别已知风险（比如开发人员离职）、可预测风险（比如第三方接口不稳定）
风险预测：评估风险发生概率和影响程度
风险评估：对比成本、进度、性能三个基准线，判断风险影响
风险控制：提前规避风险，比如招备份人员、和第三方签SLA协议
