第 05 章《软件工程基础知识》

在软考高级《系统架构设计师》考试中，官方教程第 5 章《软件工程基础知识》既是上午综合知识（固定占 8~10 分）的“高频稳拿分区”，也是下午案例分析大题中关于需求变更、系统分析设计、构件组装与质量管理的理论根基。

📌 章节知识全景导航

第 5 章 软件工程基础知识├── 5.1 软件工程与过程模型（定义/PDCA、瀑布、原型、螺旋、敏捷、RUP、CMMI）├── 5.2 需求工程（需求获取/层次、需求变更控制/CCB、双向跟踪矩阵 RTM）├── 5.3 系统分析与设计（结构化 SASD / 7种内聚类型、面向对象 OOA/OOD / 三类类）├── 5.4 软件测试（测试方法与逻辑覆盖、测试阶段、负载 vs 压力测试）├── 5.5 净室软件工程 CSE（函数/抽样理论、黑盒/状态盒/明盒、正确性验证）├── 5.6 基于构件的软件工程 CBSE（构件模型、CBSE 过程、组装与适配器构件）└── 5.7 软件项目管理（WBS 分解、配置管理 SCM、SQA、McCall 质量模型）

5.1 软件工程与软件过程模型

1. 软件工程定义与 PDCA 循环

软件工程是应用计算机科学、数学及管理科学等原理，开发软件的工程学科。其过程在工具支持下由工程师完成，包含 PDCA 循环 4 大活动：

• • P (Plan) —— 软件规格说明：规定软件功能及其运行时的限制。
• • D (Do) —— 软件开发：开发出满足规格说明的软件产品。
• • C (Check) —— 软件确认：确认开发的软件能够满足用户的实际需求。
• • A (Action) —— 软件演进：软件在运行过程中不断改进以适应新的需求。

2. 经典软件过程模型精讲

根据软件生命周期的特点，教程总结了以下主流过程模型：

• • 瀑布模型 (Waterfall Model)：
• • 特点：严格串行化，前一阶段的输出是后一阶段的输入，各阶段完成后伴随里程碑审查。
• • 适用场景：需求明确、技术成熟且极少变更的项目。
• • 局限：用户需要很长时间才能看到可运行的系统；早期需求错误会导致后期巨大的修改成本。
• • 原型化模型 (Prototype Model)：
• • 特点：通过快速构建原型来捕获和确认需求。分为抛弃型原型（确认需求后废弃，重新编码）与演化型原型（在此基础上不断补充完善成产品）。
• • 适用场景：需求模糊不清、用户无法准确表达需求的项目。
• • 螺旋模型 (Spiral Model)：
• • 特点：结合了瀑布模型和原型模型，核心标志是引入了严格的“风险分析 (Risk Analysis)”。每个迭代周期包含：目标设定、风险分析、开发与验证、评审。
• • 适用场景：庞大、复杂且高风险的软件开发。
• • 敏捷模型 (Agile Model)：
• • 核心思想：适应型开发，以人为本，采用短周期迭代增量交付。
• • 典型方法：
• • 极限编程 (XP)：4 大价值观为交流、朴素、反馈、勇气；强调结对编程、测试驱动开发 (TDD)、持续集成 (CI)。
• • Scrum：管理产品需求池 (Backlog)，以 2~4 周固定周期（Sprint 冲刺）迭代交付可工作的软件增量。
• • 统一过程模型 (RUP)：
• • 三大核心特征：用例驱动、以架构为中心、迭代和增量。
• • 生命周期 4 阶段：初始 (Inception)、细化 (Elaboration)、构建 (Construction)、交付 (Transition)。
• • “4+1”视图模型：用例视图（连接纽带）、逻辑视图（功能/概念）、进程视图（动态/性能）、实现视图（模块/代码）、部署视图（硬件/网络）。
• • 能力成熟度模型 (CMMI)：
• • Level 1 初始级：无序混乱，项目成功依赖个人英雄主义。
• • Level 2 可管理级：建立基础项目管理制度，过程可重复。
• • Level 3 已定义级：形成组织级的标准软件工程过程。
• • Level 4 已量化管理级：对过程性能进行定量/统计度量与预测。
• • Level 5 优化级：关注通过增量式与创新式的过程改进，持续提升组织绩效。

5.2 需求工程

需求工程覆盖体系结构设计之前的各项开发活动，包含需求开发与需求管理两大领域。

1. 需求的三种层次

• • 业务需求：反映组织或客户对系统高层次的目标要求（最高层）。
• • 用户需求：描述用户使用产品必须完成的任务和期望（中层）。
• • 功能需求：定义开发人员必须实现的具体软件功能，以及非功能需求（性能、质量标准等）与设计约束（底层）。

2. 需求获取方法

常见获取手段包括：用户面谈、专题讨论会、问卷调查、现场观察、原型化方法、头脑风暴法。通过系统上下文图和顶层用例图可以划定项目范围。

3. 需求变更管理与 CCB 机制

• • 变更控制委员会 (CCB)：
• • 性质：CCB 是项目的决策机构，由项目多方代表（项目管理、开发、测试、客户/市场部门等）组成。
• • 职责范围：负责评估变更影响、评审并决策是否批准变更请求。
• • 边界限制：CCB 不是作业机构，不提出具体的变更修改方案，也不自修改代码或更新项目配置库。
• • 变更跟踪要求：每一个集成的需求变更都必须能够追溯到一个经核准的变更请求，保持水平可追踪性；原始变更请求文档绝不能从配置库中删除。

4. 需求追踪与双向跟踪矩阵 (RTM)

需求追踪建立并维护“需求-设计-编程-测试”之间的一致性：

• • 正向跟踪：检查《需求规格说明书》中的每个需求是否都能在后续工作成果（设计/代码/测试）中找到对应点。
• • 逆向跟踪：检查后续工作成果（设计/代码/测试）是否能在《需求规格说明书》中找到出处。
• • 正逆向结合称为 “双向跟踪”，在工程中通过 《需求跟踪矩阵 (RTM)》 保存和维护。

5.3 系统分析与设计

系统分析是将复杂问题分解为抽象模型；系统设计是根据分析结果绘制构建系统的蓝图（概要设计与详细设计）。

1. 结构化分析与设计 (SASD)

结构化方法遵循“分解与抽象、模块独立性、信息隐蔽”原则，追求 “高内聚、低耦合”。

• • 7 种模块内聚类型（按内聚度从高到低排序，选择题高频）：

2. 面向对象分析与设计 (OOA/OOD)

面向对象方法建立在“对象”基础上，以用例驱动、以架构为中心、迭代增量。

• • OOD 中的三类核心类（案例题与场景识别必考）：
• • 实体类 (Entity Class)：映射持久化存储的业务数据（如数据库表对应的订单、客户、商品类）。通常有属性，生命周期与系统一致。
• • 控制类 (Control Class)：封装用例特有的控制行为与工作流逻辑（如“身份验证器”、“计费处理器”）。通常以动宾结构命名，有方法无属性，用例执行完即消亡。
• • 边界类 (Boundary Class)：封装系统与外部环境、外部系统或用户的交互数据流。包括所有窗口、用户界面、报表、打印机/摄像头接口、传感器及通信协议接口。

5.4 软件测试

软件测试是在预定条件下运行系统，评估其是否符合规定需求的过程。

1. 测试方法分类

• • 静态测试 vs 动态测试：静态测试不运行程序（代码审查、结构分析）；动态测试运行程序并对比实际与预期输出。
• • 黑盒 vs 白盒 vs 灰盒：
• • 黑盒测试：不考虑程序内部结构，只针对功能接口测试（等价类划分、边界值分析、因果图）。
• • 白盒测试：基于程序内部结构和逻辑路径设计测试用例。白盒覆盖强度逻辑为：语句覆盖 < 判定覆盖 < 条件覆盖 < 路径覆盖。
• • 灰盒测试：介于黑盒与白盒之间，结合内部逻辑标记与输出结果进行验证。

2. 测试阶段与性能测试辨析

• • 测试阶段：单元测试（模块级/白盒） → 集成测试（接口与组装） → 系统测试（全系统功能与性能/黑盒） → 验收测试。
• • 验收测试分类：Alpha 测试（在开发环境下由用户进行）与 Beta 测试（在实际真实环境中由多个用户进行）。
• • 性能测试（负载测试 vs 压力测试）：
• • 负载测试 (Load Testing)：在各种工作负载下测试，观察负载逐渐增加时系统各项性能指标（响应时间、吞吐量、资源利用率）的变化情况。
• • 压力测试 (Stress Testing)：测试系统的瓶颈或不可接受点，获得系统能提供的最大服务级别与极限承载能力（持续加压直至崩溃）。

5.5 净室软件工程 (CSE)

净室软件工程是一种应用数学与统计学理论以经济方式生产高质量软件的工程技术，力图在开发中达到零缺陷。

• • 核心哲学：强调在第一时间内正确书写代码增量，并在测试前通过正确性验证（而非依赖传统单元测试排错）来避免高成本错误。
• • 理论基础：函数理论（完备性、一致性、正确性）与抽样理论。
• • 技术手段（3 种盒子结构）：
• • 黑盒：外部行为视图。
• • 状态盒：有限状态机视图。
• • 明盒：过程与代码实现视图。
• • 质量认证：使用基于使用模型的统计测试（使用模型产生随机样本）进行质量认证和可靠性评估。

5.6 基于构件的软件工程 (CBSE)

CBSE 是一种强调通过复用现成软件构件来构建系统的工程方法。

• • 构件与构件模型：构件是可重用、独立的二进制执行实体。构件模型提供平台服务（分布式通信）与支持服务（如安全认证），构件运行于容器中。
• • CBSE 开发过程：
1. 1. 系统需求概览
2. 2. 识别候选构件
3. 3. 根据发现的构件修改需求
4. 4. 体系结构设计
5. 5. 构件定制与适配
6. 6. 组装构件，创建系统
• • 接口不兼容解决方案：当候选构件的接口与系统的请求接口在参数类型、操作名称上出现不兼容时，标准解法是编写适配器构件 (Adapter) 进行接口转换与适配。

5.7 软件项目管理

软件项目管理是为了使软件项目能够按照预定的成本、进度和质量顺利完成，对 人员 (People)、产品 (Product)、过程 (Process) 和项目 (Project)（即 4P）进行的管理活动。

• • 软件进度管理：
• • WBS（工作分解结构）：将复杂项目层层分解为单一、可管理的小任务（工作包），每个工作包必须有明确的交付成果和完成标准。
• • 任务活动图与甘特图：定义活动的前驱、持续时间与里程碑，绘制活动图进行进度计划与监控。
• • 配置管理 (SCM)：核心活动是版本控制与变更控制，标识并控制系统制品的修改，确保变更有序进行。
• • 软件质量保证 (SQA)：关注事前预防而非事后检查，作用于开发过程而非仅作用于最终产品，贯穿于所有开发活动中。
• • McCall 软件质量模型（3 组用户倾向）：

               ┌── 产品运行：正确性、可靠性、效率、完整性、易用性/可用性               │McCall 质量模型 ┼── 产品修改：可维护性、灵活性、可测试性               │               └── 产品转移：可移植性、可再用性、互操作性

🧠 全章核心速记口诀

1. 过程模型选型：   需求明确瀑布走，需求模糊原型凑；   风险分析选螺旋，拥抱变化敏捷跑！2. 模块内聚类型（高到低）：   功能内聚最高级，顺序输出变输入；   通信过程时间逻辑，偶然内聚最低级！3. OOD 三类类区分：   实体存数据，控制管逻辑，边界跨内外！4. 性能测试双子星：   负载看逐渐加压，压力测崩溃极限！5. 接口不兼容解法：   构件接口不匹配，统一选适配器 (Adapter)！6. McCall 模型 3 倾向：   • 产品运行：正确可靠效率高   • 产品修改：维护灵活可测试   • 产品转移：移植再用互操作

💡 下期预告与互动：下一期我们将进入 第 6 章《数据库设计基础知识》，带大家硬核拆解 规范化范式（1NF 到 4NF）、分布式数据库（CAP/BASE 理论）、E-R 图转关系模式与 SQL 性能优化！你在复习第 5 章时，觉得哪个知识点最容易混淆？欢迎在评论区留言交流！如果本文对你的备考有帮助，别忘了 点赞、在看、分享 支持一下，我们下一期见！🚀