speedrun5｜第5章 软件工程基础知识

ONEPSOFT | 软考学习知识库

---

speedrun5｜第5章 软件工程基础知识

第 5 章 软件工程基础知识 — 知识点速通

一、章节定位

一句话概括：本章讲软件工程的定义与过程、软件过程模型（瀑布/原型/螺旋/敏捷/RUP）、CMM/CMMI、需求工程、系统分析与设计（结构化/面向对象）、软件测试、净室/构件软件工程、软件项目管理；是架构 " 如何把设计落地为软件 " 的方法论基础，约占 10%\\~14% 权重，综合知识 + 案例双重点区。

• 题型覆盖：综合知识 ✓ ｜ 案例分析 ✓（过程模型选型/需求变更/测试/配置管理） ｜ 论文 ✓（过程/质量管理素材）
• 重要性等级：★★★★★——过程模型、需求工程、测试、CMMI、配置管理是超高频考点
• 教材出处：第 5 章 软件工程基础知识

二、本章在讲什么（系统性阐述）

软件工程是 " 用工程化方法开发维护软件 "。本章先给软件工程定义与软件危机背景、软件过程 PDCA 四活动，再系统讲软件过程模型：瀑布（严格串行）、原型（快速确认）、螺旋（风险驱动四阶段）、敏捷（2001 宣言、适应型/以人为本）、RUP（9 工作流、用例驱动、迭代增量）与 CMM/CMMI 五级成熟度。接着是需求工程（获取/分析/规格/确认/管理、变更控制、双向追踪）与系统分析设计（结构化 DFD/高内聚低耦合 7 类耦合 7 类内聚、面向对象封装继承多态）。然后是软件测试（静态/动态、黑/白/灰盒、单元/集成/系统）、净室与基于构件的软件工程（复用、购买而非建造），最后落到软件项目管理（进度 WBS、配置管理版本/变更、质量 SQA、风险 Boehm 体系）。

对土木考生：软件过程模型像不同的施工组织模式——瀑布像 " 按图施工、上道工序验收合格才进下道 "，原型像 " 先做样板间给业主确认再正式建 "，螺旋像 " 边干边做风险评估的 EPC"，敏捷像 " 业主全程驻场、短周期交付可住房型 "；高内聚低耦合像 " 每个分包职责单一、包间接口最少 "；软件配置管理 (版本/变更) 像 " 施工图版本管理与设计变更单 "——这正是你薄弱的 IT 运维/配置管理在软件侧的对应。

三、教材原文精摘（原封不动，逐子章节全覆盖）

下列段落直接摘自官方教材，未做任何改写。

【5.1 软件工程 原文】" 软件危机的具体表现：软件开发进度难以预测；软件开发成本难以控制；软件功能难以满足用户期望；软件质量无法保证；软件难以维护；软件缺少适当的文档资料。"

"IEEE：软件工程是：①将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件；②对①中所述方法的研究。"

" 软件工程过程 4 方面（PDCA）：(1) P(Plan)——软件规格说明。(2) D(Do)——软件开发。(3) C(Check)——软件确认。(4) A(Action)——软件演进。"

【5.1.2 软件过程模型 原文】" 瀑布模型 (Waterfall Model) ……因果关系紧密相连，前一个阶段工作的输出结果，是后一个阶段工作的输入。"

" 原型模型 (Prototype Model) 又称快速原型……抛弃型原型是将原型作为需求确认的手段……演化性原型是在需求确认结束后，不断补充和完善原型，直至形成一个完整的产品。"

" 螺旋模型 (Spiral Model) ……每一个阶段都由 4 部分组成：(1) 目标设定。(2) 风险分析。(3) 开发和有效性验证。(4) 评审。"

【5.1.3 敏捷模型 原文】"2001 年 2 月，17 位著名的软件开发专家……正式提出了 Agile (敏捷) 的概念，并共同签署了敏捷宣言。"

" 敏捷型方法是 ' 适应性 '(adaptive) 而非 ' 预设性 '(predictive) 的。"" 敏捷型方法是 ' 面向人的 '(People-oriented) 而非 ' 面向过程的 '(Process-oriented)。"" 核心思想：(1) 敏捷方法是适应型，而非可预测型。(2) 敏捷方法是以人为本，而非以过程为本。(3) 迭代增量式的开发过程。"

【5.1.4 统一过程模型 (RUP) 原文】"RUP 是用例驱动的、以体系结构为中心的、迭代和增量的软件开发过程。""9 个核心工作流：业务建模、需求、分析与设计、实现、测试、部署、配置与变更管理、项目管理、环境。"

【5.1.5 软件能力成熟度模型 原文】"Level 1 初始级：过程通常是随意且混乱的。Level 2 已管理级……Level 3 已定义级：企业能够根据自身的特殊情况定义适合自己企业和项目的标准流程。Level 4 量化管理级……Level 5 优化级：关注于通过增量式地与创新式的过程与技术改进，不断地改进过程性能。"

"CMMI……用于指导软件开发过程的改进和进行软件开发能力的评估。"

【5.2 需求工程 原文】" 需求工程是指应用已证实有效的原理、方法，通过合适的工具和记号，系统地描述待开发系统及其行为特征和相关约束。"

" 软件需求 3 层次：(1) 业务需求。(2) 用户需求。(3) 功能需求……非功能性需求对设计和实现提出了限制。"

" 变更控制过程：(1) 问题分析和变更描述。(2) 变更分析和成本计算。(3) 变更实现。"" 变更控制委员会 (CCB)：是项目所有者权益代表，负责裁定接受哪些变更。"

" 需求跟踪有两种方式：(1) 正向跟踪。检查需求是否都能在后继工作成果中找到对应点。(2) 逆向跟踪。检查设计文档、代码、测试用例等是否都能在需求规格说明书中找到出处。"" 正向跟踪和逆向跟踪合称为 ' 双向跟踪 '……需求跟踪矩阵保存了需求与后继工作成果的对应关系。"

【5.3 系统分析与设计 原文】" 耦合 7 类（低→高）：非直接耦合、数据耦合、标记耦合、控制耦合、通信耦合、公共耦合、内容耦合。"" 内聚 7 类（高→低）：功能内聚、顺序内聚、通信内聚、过程内聚、时间内聚、逻辑内聚、偶然内聚。"

" 在模块的分解中应尽量减少模块的耦合，力求增加模块的内聚，遵循 ' 高内聚、低耦合 ' 的设计原则。"

"OOP=对象 + 类 + 继承 + 多态 + 消息。"" 封装是指将数据及操作语言封装在一个 ' 模块 '（类）中。"

【5.4 软件测试 原文】"(1) 静态测试：被测程序不运行，只依靠分析或检查源程序……(2) 动态测试：通过运行被测试程序……(3) 黑盒测试：将被测程序看成是一个黑盒……(4) 白盒测试：借助程序内部的逻辑和相关信息……(5) 灰盒测试。"

" 单元测试……集成测试……系统测试：一般情况下，系统测试采用黑盒测试……主要测试内容包括功能测试、性能测试、健壮性测试、安装或反安装测试、用户界面测试、压力测试、可靠性及安全性测试等。"

【5.5 净室软件工程（参考大纲/常见考点）】净室软件工程 " 力图通过严格的工程化的软件过程达到开发中的零缺陷或接近零缺陷 "，理论基础为函数理论与抽样理论，技术手段含统计过程控制下的增量开发、正确性验证、统计测试与认证。

【5.6 基于构件的软件工程 CBSE 原文】" 用于 CBSE 的构件应该具备以下特征：(1) 可组装性；(2) 可部署性；(3) 文档化；(4) 独立性；(5) 标准化。"

" 不兼容情况：(1) 参数不兼容。(2) 操作不兼容。(3) 操作不完备。"" 必须通过编写适配器构件来解决不兼容的问题。"

【5.7 软件项目管理 原文】" 软件进度管理一般包括：活动定义、活动排序、活动资源估计、活动历时估计、制定进度计划和进度控制。"" 工作分解结构 (WBS)：项目→任务→工作→日常活动。"

" 软件配置管理核心内容包括版本控制和变更控制。"

" 软件质量就是软件与明确地和隐含地定义的需求相一致的程度……软件质量保证 (SQA)：目标是使软件过程对于管理人员来说是可见的……事先预防工作，例如，着重于缺陷预防而不是缺陷检查。"

"Boehm 的软件风险管理体系，把风险管理活动分成风险估计……和风险控制……两大阶段。"

逐段讲解（紧贴上面原文，一段一解）：

• 针对 5.1 原文：软件危机 6 表现（进度/成本/功能/质量/维护/文档），IEEE 定义 " 工程化应用于软件 "，PDCA 四活动（规格/开发/确认/演进）。
• 针对 5.1.2 原文：瀑布严格串行、原型分抛弃/演化、螺旋风险驱动四阶段——三者选型是案例高频。
• 针对 5.1.3 原文：敏捷 2001 宣言、适应型/以人为本/迭代增量，方法含 XP/Scrum/FDD。
• 针对 5.1.4 原文：RUP 用例驱动、以架构为中心、迭代增量，9 工作流。
• 针对 5.1.5 原文：CMM/CMMI 五级（初始/已管理/已定义/量化管理/优化），案例 " 过程改进 " 必考。
• 针对 5.2 原文：需求三层（业务/用户/功能）+ 非功能；变更三步骤 +CCB；双向跟踪 + 跟踪矩阵。
• 针对 5.3 原文：7 类耦合（低→高）、7 类内聚（高→低）， " 高内聚低耦合 " 是设计铁律；OO=对象 + 类 + 继承 + 多态 + 消息。
• 针对 5.4 原文：静态/动态、黑/白/灰盒分类；测试四阶段（单元/集成/系统/验收），系统测试黑盒含功能/性能/压力等。
• 针对 5.5 原文：净室追求零缺陷，理论函数 + 抽样，偏学术。
• 针对 5.6 原文：构件 5 特征（可组装/部署/文档/独立/标准），不兼容三类靠适配器解决； " 购买而非建造 " 是复用哲学。
• 针对 5.7 原文：进度 WBS（项目→任务→工作→日常）；配置管理版本 + 变更；SQA 重缺陷预防；Boehm 风险估 + 控。

四、核心知识树

第 5 章 软件工程基础知识

├── 软件工程与过程

│ ├── 危机与定义

│ └── PDCA 四活动

├── 过程模型

│ ├── 瀑布原型螺旋

│ ├── 敏捷 RUP

│ └── CMM 五级

├── 需求与设计

│ ├── 需求工程

│ └── 高内聚低耦合

└── 测试与管理

├── 测试分类

├── 构件复用

└── 配置质量风险

五、知识脑图总结

思维导图（结构化呈现）

• 第5章 软件工程
  • 软件工程与过程
    • 危机与定义
    • PDCA四活动
  • 过程模型
    • 瀑布原型螺旋
    • 敏捷RUP
    • CMM五级
  • 需求与设计
    • 需求工程
    • 高内聚低耦合
  • 测试与管理
    • 测试分类
    • 构件复用
    • 配置质量风险

六、关键概念速解

概念	教材定义（原文关键词）	大白话速解	考试怎么考
软件危机	" 进度难预测、成本难控制、质量无法保证、难以维护、缺文档 "	工程烂尾/超支/返工	选择
瀑布模型	" 前一阶段输出是后一阶段输入，严格串行 "	按图施工、上道验收才进下道	选择/案例
敏捷	" 适应性而非预设性、以人为本、迭代增量 "	业主驻场、短周期交付可住房型	选择/案例
高内聚低耦合	" 减少耦合、增加内聚 "	每分包职责单一、接口最少	选择/案例
需求双向跟踪	" 正向 + 逆向跟踪，保存需求与成果对应 "	设计/代码/测试都能溯源到需求	选择/案例
配置管理	" 版本控制 + 变更控制 "	施工图版本管理与设计变更单	选择（运维）

七、记忆口诀 & 类比

• 口诀：「危机六现，PDCA 规开确演；瀑布串、原型样、螺旋险、敏捷人、RUP 九流用例架；CMM 五初管定量化优；需求三层双向跟、CCB 裁变更；高内聚低耦合七七分；测试静动黑百灰、单元集成系统收；配置版本变更、SQA 防缺陷、Boehm 估控险」→ 对应全章主干。
• 类比：① 过程模型像施工组织模式——瀑布=按图施工上道验收才进下道、原型=先做样板间确认再正式建、螺旋=边干边做风险评估的 EPC、敏捷=业主全程驻场短周期交付。② 高内聚低耦合像专业分包：每个分包职责单一（高内聚）、包间接口最少（低耦合）。③ 软件配置管理 (版本/变更) 像施工图版本管理与设计变更单——这正是 IT 运维/配置管理在软件侧的对应，也是你薄弱点的落点。

八、易混淆点对比

易混项 A	易混项 B	核心区别
瀑布模型	原型模型	瀑布严格串行、一次交付；原型先建样板确认（抛弃/演化）
螺旋模型	敏捷模型	螺旋风险驱动四阶段、重量级；敏捷适应型/以人为本/短迭代
黑盒测试	白盒测试	黑盒看功能不看内部；白盒看内部逻辑
正向跟踪	逆向跟踪	正向：需求→成果；逆向：成果→需求（合为双向跟踪）
内容耦合 (最高)	非直接耦合 (最低)	耦合由低到高，内容耦合最差；内聚由高到低，功能内聚最好

九、与其他章节的关联

• 上游 / 前置：第 1 章（架构设计落地为软件）、第 3 章（信息系统开发方法对应）。
• 下游 / 依赖：后续 " 软件架构设计（风格/质量属性/ATAM）"" 架构评估 " 均建立在过程模型、需求工程、质量属性之上；CMMI 与系规/高项的过程管理呼应。
• 联动考点：需求工程 + 配置管理常与案例 " 需求变更/版本失控 " 合并；CMMI 五级与 " 过程改进 " 论文/案例高频；测试与质量属性（可靠性）联动。

十、考试出题方式

• 选择题：考软件危机表现、过程模型特点、敏捷宣言、RUP 9 工作流、CMMI 五级、耦合/内聚 7 类、测试分类、需求跟踪。
• 案例分析：给场景选过程模型/写需求变更控制流程/补测试阶段/配配置管理；或是 " 质量属性 + 过程 " 综合题。
• 论文：过程改进、质量管理、需求与配置管理方向的核心素材。

专项突破提醒（命中薄弱点 " 运维服务 / IT 服务 "）

本章 5.7.3 软件配置管理（版本控制 + 变更控制）与软件生命周期中的 " 维护 " 是 IT 运维/配置管理在软件工程侧的教材落点，结合你同备的高项/系规 IT 服务管理，给出 3 条可操作建议：

1. 把 " 配置管理 " 直接映射 ITIL/ITSS 配置管理：教材的 " 版本控制 + 变更控制 " 就是运维配置管理库 (CMDB) 与变更管理流程的软件侧原型——做题遇到 " 上线后怎么管版本/怎么控变更 "，直接用本章 CCB+ 变更三步骤（问题分析与描述→影响/成本分析→实现）套运维变更流程。
2. 用工程场景固化 " 变更控制 "：把需求/设计变更类比成 " 设计变更单 "——任何改动先经 CCB（业主/监理/设计代表）裁定，再走影响分析与实现；这个类比同时覆盖架构（本章）与系规（IT 服务变更）两科，避免混淆 " 开发期变更 " 与 " 运维期变更 "。
3. 做一道跨章联动题：以 " 某系统上线后的配置管理与运维交接方案 " 为题，把 5.7.3 配置管理 + 5.2 需求双向跟踪（运维期可追溯性）+ 你的 IT 服务管理知识写成案例作答，强化 " 架构/开发就要为运维可维护性、可追溯性留接口 " 的意识。