软考中级 · 系统集成项目管理工程师（第3版）｜综合知识精读

第5章 软件工程

综合篇 · 核心考点精讲（教材第3版 第202–233页）

📌 考情导航

 第5章是上午选择题分值占比最高的核心章节之一，同时也是下午案例分析的高频命题区（常考需求变更流程、模块设计（内聚耦合）、测试流程与依据）。本章分值稳定在 6–9 分左右。重点集中在： ①需求三层次与 QFD 三类、②结构化分析三模型与数据字典、③高内聚低耦合（耦合7种/内聚7种）、④OOD 七大原则、⑤UML 14图与5视图、⑥测试方法与四阶段依据、⑦CSMM 五级成熟度。 建议按「需求 → 设计 → 实现 → 部署 → 质量 → 成熟度」这条软件生命周期主线串起来记，避免零散背诵。 

一、本章知识框架

第5章以软件生命周期为主线，覆盖从需求到退役的完整过程，整体结构如下：

① 软件工程定义（5.1）：定义 / 方法·工具·过程三要素

② 软件需求（5.2）：需求层次 / QFD / 需求获取 / 需求分析（SA·OOA）/ SRS / 需求变更 / 需求跟踪

③ 软件设计（5.3）：结构化设计 SD / 面向对象设计 OOD / UML / 设计模式

④ 软件实现（5.4）：配置管理 / 编码 / 测试

⑤ 部署交付（5.5）：部署模式 / 交付 / 持续交付 / 持续部署 / 新趋势

⑥ 软件质量管理（5.6）：SQA / McCall 质量三因素

⑦ 软件过程能力成熟度（5.7）：CSMM 四大能力域 / 五级成熟度

一句话定位：软件工程 = 用工程化的方法解决软件问题，目标是提高生产率、提高质量、降低成本；三要素是方法、工具、过程。 

二、5.1 软件工程定义

软件工程是应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程，其目的是提高软件生产率、提高软件质量、降低软件成本。

软件工程由方法、工具、过程三个部分组成（三要素，选择/案例均常考）：

🔵 理解：「方法」解决怎么做，「工具」提供支撑环境，「过程」规定先做什么后做什么——三者缺一不可，构成软件工程的完整体系。

三、5.2 软件需求（重中之重）

1. 需求的三个层次（5.2.1）

软件需求分为业务需求、用户需求、系统需求三个层次，自上而下层层细化：

• 业务需求：组织机构或用户对系统、产品高层次的目标要求，描述「为什么要做这个系统」，体现组织战略目标，用于确定项目视图和范围。

• 用户需求：用户要求系统必须完成的任务和想要达到的结果，描述「用户能用系统做什么」，构成用户原始需求文档。

• 系统需求：从系统角度说明软件需求，包括三部分： 功能需求（系统必须实现的功能）、 非功能需求（系统必须具备的属性或品质，如易用性、可维护性、效率等）、 约束（对设计和构造的限制，如设计约束「必须采用自主知识产权数据库」、过程约束「必须运行在开源操作系统之下」）。

🟢 口诀记忆：业务需求＝「我要建一栋别墅」（为什么要建）；用户需求＝「要有卧室、厨房、卫生间」（能做什么）；系统需求＝「卧室20平米、环保材料、电路暗埋」（具体怎么做、受什么限制）。 

2. 质量功能部署 QFD（5.2.2）

质量功能部署（Quality Function Deployment, QFD）是一种将用户要求转化成软件需求的技术，目的是最大限度地提升软件工程过程中用户的满意度。QFD 将软件需求分为三类：

易错点：三类需求中，只有「意外需求」不实现也不影响购买决策；「期望需求」不实现会直接导致不满意——这是命题人最爱挖的坑。

图1 · 需求三层次与 QFD 三类需求对照

3. 需求获取（5.2.3）

需求获取是确定和理解不同项目干系人对系统的需求和约束的过程。常用方法包括：用户访谈、问卷调查、采样、情节串联板、联合需求计划（JRP）等。

难点在于用户往往说不清自己到底要什么，且需求会不断变化，因此需求获取不是一次性工作，需要反复沟通与确认。

4. 需求分析（5.2.4）

需求分析把获取到的杂乱需求整理成清晰、一致、可验证的需求。一个好的需求应具备：无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性。

（1）结构化分析 SA——面向数据流，核心是数据字典

• 数据模型：用实体关系图（E-R 图）描述实体、属性和关系；

• 功能模型：用数据流图（DFD）描述数据传递和加工过程；

• 行为模型：用状态转换图（STD）描述系统状态和引发状态转换的事件。

DFD 数据流图由四种基本元素组成：数据流（箭头，数据流向）、加工/处理（对数据的加工）、数据存储（数据存放的地方）、外部项/外部实体（数据源或终点）。

数据字典是关于数据的信息集合，是对 DFD 中所有元素的详细说明，就像一本「数据百科全书」。其条目包括：数据元素、数据结构、数据流、数据存储、加工逻辑（处理过程）、外部实体。

图2 · 结构化分析 SA：数据字典 + 三大模型

（2）面向对象分析 OOA——从对象的角度分析问题域

• 五个层次：主题层、对象类层、结构层、属性层、服务层（口诀：主象结务属）；

• 两种结构：分类结构（一般—特殊）、组装结构（整体—部分）；

• 基本原则：抽象、封装、继承、分类、聚合、关联、消息通信、粒度控制、行为分析；

• 核心模型：用例模型 + 分析模型。

5. 需求规格说明书 SRS（5.2.5）

软件需求规格说明书（SRS）是需求分析的产物和文档化结果，是软件开发过程中最重要的文档之一。它是后续软件设计、测试、验收的依据，也是用户与开发人员之间的合同。

6. 需求变更（5.2.6）｜案例高频

教材给出的需求变更管理过程为五步（默写考点）：

识别问题 → 问题分析和变更描述 → 变更分析和成本计算 → 变更实现 → 修改后的需求

CCB 变更控制委员会：是项目所有者权益代表，属于决策机构而非作业机构——负责裁定接受哪些变更，通常不提出变更方案。这是选择题的经典陷阱：题目若说「CCB 负责提出变更方案」，即为错误表述。

7. 需求跟踪（5.2.7）

• 正向跟踪：检查 SRS 中的每个需求是否都能在后继工作产品（设计、代码、测试）中找到对应点；

• 逆向跟踪：检查设计文档、代码、测试用例等工作产品是否都能在 SRS 中找到出处。

正向与逆向合称双向跟踪，工程上通过需求跟踪矩阵实现。

四、5.3 软件设计（本章最难、分值最集中）

1. 结构化设计 SD（5.3.1）

结构化设计是一种面向数据流的设计方法，与 SA 相衔接。核心思想是自顶向下、逐层分解、模块化。分为两大阶段：

• 概要设计（总体设计）：确定软件系统的结构、进行模块划分、定义模块功能与接口 → 产出模块结构图（SC）和概要设计说明书；

• 详细设计：确定每个模块内部的算法和数据结构 → 产出详细设计说明书。

模块具有功能、逻辑、状态三个基本属性。衡量模块独立性的标准是「高内聚、低耦合」——这是本章最高频的考点。

（1）耦合：模块之间联系的紧密程度（越低越好）

（2）内聚：模块内部各元素结合的紧密程度（越高越好）

🟢 口诀（必背）： 耦合从低到高：非 → 数 → 标 → 控 → 通 → 公 → 内（「非数标控通公内」） 内聚从高到低：功 → 顺 → 通 → 过 → 时 → 逻 → 偶（「功顺通过间逻偶」） 记住两端即可：最理想＝功能内聚 + 非直接耦合；最糟糕＝偶然内聚 + 内容耦合。 

图3 · 模块独立性：耦合七种与内聚七种对照

2. 面向对象设计 OOD（5.3.2）

OOD 是 OOA 的继续，将分析阶段得到的模型转化为可实现的系统设计。七大设计原则（口诀：单开里依接组迪）：

OOD 三类核心类（选择/案例常考）：

• 实体类：映射现实中的每个实体，保存永久数据，通常有属性无操作；

• 控制类：控制用例流程，通常无属性有方法；

• 边界类：系统与外界交互的接口（如窗体、报表、硬件接口）。

图4 · OOD 七大设计原则与三类核心类

3. 统一建模语言 UML（5.3.3）

UML 的结构包括构造块、规则、公共机制三部分，其中构造块又包含事物、关系、图。

（1）四种关系：依赖、关联、泛化（继承）、实现。

（2）14 种图——分为静态图（结构图）与动态图（行为图）各 7 种：

（3）五大视图（4+1 视图）：

• 用例视图：最基本的需求分析模型，展示外部角色看到的系统功能；

• 逻辑视图（设计视图）：系统的静态结构和动态行为；

• 进程视图：并发与同步结构（线程、进程）；

• 实现视图：物理代码和构件的组织；

• 部署视图：软件到硬件的映射与分布。

🔵 易混辨析：三种交互图的区别——顺序图强调消息的时间次序；通信图强调对象间的结构组织；定时图强调实际时间约束。

图5 · UML 14 种图与五大视图

4. 设计模式（5.3.4）

设计模式按目的分为创建型、结构型、行为型三类（GoF 23 种）：

五、5.4 软件实现

1. 软件配置管理（5.4.1）

软件配置管理（SCM）主要用于标识、组织和控制修改，核心内容是版本控制与变更控制。六大活动（口诀：计标控记审发）：

配置管理计划 → 配置标识 → 配置控制 → 配置状态记录 → 配置审计 → 发布管理与交付

2. 软件测试（5.4.3）｜高频

测试目的：发现软件错误。成功的测试是发现了至今尚未发现的错误的测试——这一点常被考到。

（1）测试方法：静态 vs 动态

• 静态测试：不运行程序，通过人工或工具检查。包括文档检查、代码走查、代码审查；

• 动态测试：运行程序。分为 白盒测试（结构测试，检查内部逻辑路径，主要用于单元测试；技术有逻辑覆盖、循环覆盖、基本路径测试）与 黑盒测试（功能测试，不考虑内部结构，检查功能是否满足需求，用于集成测试和系统测试；技术有等价类划分、边界值分析、判定表、因果图）。

（2）测试阶段与依据（必背对照表）

Alpha 测试：用户在开发环境下进行的测试；Beta 测试：用户在实际使用环境下进行的测试。

软件调试与测试不同——调试的目的是定位并修复错误，常用策略有蛮力法、回溯法、原因排除法。

图6 · 软件测试体系：方法分类与四阶段依据

六、5.5 部署交付（近年热点）

1. 三种部署模式（5.5.1）

• 单机部署：适用于单机软件；

• 集中式服务器部署：适用于 500 人以下的中小组织；

• 微服务分布式部署：适用于高并发、云原生应用，需容器和 DevOps 支持。

2. 两种核心部署策略（会区分）

• 蓝绿部署：同时运行新旧两个版本，通过域名切换流量 → 优势是快速回滚、无停机时间；

• 金丝雀部署：先让少量用户使用新版本，验证无误后全量发布 → 优势是风险小、逐步验证。

3. 持续交付与持续部署（5.5.3–5.5.4）

持续交付的优势：缩短部署时间、降低风险、快速反馈缺陷、软件始终可部署、交付过程可靠可预期。

与持续部署的区别在于：持续交付的最后一公里（发布到生产环境）由人工决定；持续部署则全自动发布到生产环境。

图7 · 部署交付：三种模式、两种策略与 CI/CD 流水线

七、5.6 软件质量管理

软件质量保证 SQA：建立一套有计划、有系统的方法，确保软件过程和产品符合标准。核心目标：缺陷预防而非缺陷检查，作用于过程而非最终产品。主要任务：SQA 审计与评审、SQA 报告、处理不合格问题。

软件质量三大因素（McCall 质量模型 11 特性）：

八、5.7 软件过程能力成熟度

1. CSMM 四大能力域（5.7.1）

• 治理：战略与治理、目标管理；

• 开发与交付：需求、设计、开发、测试、部署、服务、开源应用；

• 管理与支持：项目策划、监控、结项、质量保证、风险管理、配置管理、供应商管理；

• 组织管理：过程管理、人员能力、组织资源、过程能力。

2. 五级成熟度等级（5.7.2）｜必背

🟢 口诀（必背）：一不二计三稳四量五创 —— 一「不」确定、二「计」划实现、三「稳」定实现、四「量」化管理、五「创」新引领。 

⚠️ 超级易错点：第3版教材用的是 CSMM（软件过程能力成熟度模型），不是 CMMI！两者等级名称完全不同： · CSMM：初始级 / 项目规范级 / 组织改进级 / 量化提升级 / 创新引领级 · CMMI：初始级 / 已管理级 / 已定义级 / 量化管理级 / 优化级 很多老资料仍写 CMMI，看到题目选项时务必看清楚是「项目规范级」还是「已管理级」。 

图8 · CSMM 四大能力域与五级成熟度

九、高频易混点速查

十、本章自测（5 题）

1. 在质量功能部署（QFD）中，用户想当然认为系统应具备、但未实现会引起不满的需求称为（　）。A 常规需求　B 期望需求　C 意外需求　D 业务需求

2. 结构化分析方法的核心是（　）。A 数据流图　B E-R 图　C 数据字典　D 状态转换图

3. 下列耦合中，耦合度最低、模块独立性最好的是（　）。A 数据耦合　B 标记耦合　C 非直接耦合　D 控制耦合

4. 集成测试的技术依据是（　）。A 详细设计说明书　B 概要设计说明书　C 需求规格说明书　D 开发合同

5. 软件过程能力成熟度模型 CSMM 的最高等级是（　）。A 量化提升级　B 组织改进级　C 优化级　D 创新引领级

✅ 参考答案

 1. B（期望需求：不实现会让用户不满意；意外需求不实现也不影响购买决策） 2. C（数据字典是 SA 核心，三模型围绕它展开） 3. C（非直接耦合最低；口诀「非数标控通公内」） 4. B（单元测试→详细设计；集成测试→概要设计；确认/系统测试→需求规格说明书） 5. D（CSMM 五级：初始→项目规范→组织改进→量化提升→创新引领） 

 📚 本系列持续更新中，覆盖中项第3版全部 18 章。关注「软考高项自习室」，陪你稳稳上岸。