文章目录
-
一、开发模型与信息系统开发方法（题号：1, 2, 4, 17, 18, 19, 20, 32）
-
二、需求工程与结构化分析（题号：3, 9）
-
三、软件设计（耦合与设计活动）（题号：16, 21, 22）
-
四、面向对象设计原则（OOD）（题号：26, 27）
-
五、设计模式（题号：23, 34）
-
六、UML 与面向对象分析（题号：10, 11, 12, 13, 24, 25, 35）
-
七、软件测试与调试（题号：5, 6, 7, 8, 33）
-
八、系统演进、切换与维护（题号：14, 15, 30, 31）
-
九、逆向工程（题号：28, 29）
一、开发模型与信息系统开发方法
1
知识点： 软件工程 > 开发模型 > 构件组装模型
答案：B
解析：
构件组装模型强调"先设计组装方案，再准备/获取构件并形成构件库，然后进行系统组装，最后测试发布"。因此一般开发过程可概括为：
- 设计构件组装（⑤）：在需求明确后进行体系结构与组装结构设计，明确构件职责与接口关系
- 建立构件库（②）：开发、复用或采购构件并纳入构件库，形成可检索与可复用的构件资产
- 构建应用软件（③）：按组装结构把构件集成到应用中，完成系统搭建与集成实现
- 测试与发布（①）：对组装后的系统进行集成测试/系统测试，通过验收后发布
构件的修改与维护（④）属于系统运行后的维护阶段活动，不属于"开发过程的一般顺序"中的主流程步骤，因此不应插入到 ⑤②③① 的主流程中。对应选项 B。
2
知识点： 软件工程 > 信息系统开发方法 > 敏捷开发
答案：C
解析：
敏捷的核心思想强调"适应变化、迭代增量、以人为本"，而不是强调流程的刚性与强可预测性。
- ①"适应型而非可预测型"符合敏捷强调对变化的快速响应
- ②"迭代增量式开发"是敏捷常见交付方式
- ③"以人为本而非以过程为本"符合敏捷价值观（个体与互动高于流程与工具）
- ④"强调以过程为本"与敏捷价值观相反
- ⑤"强调可预测性"更贴近计划驱动/预测型方法的目标，不是敏捷核心诉求
因此，不属于敏捷核心思想的是 ④ 和 ⑤，对应选项 C。
4
知识点： 软件工程 > 其它 > 净室软件工程
答案：C
解析：
净室软件工程（Cleanroom）强调"先保证正确，再用统计手段度量可靠性"，其核心在于通过形式化/半形式化的方法对软件进行正确性论证与验证，尽量在进入测试之前就把缺陷消除到接近零的水平。
常见的净室软件工程技术要点包括：
- 正确性验证：以规约为依据，通过证明、推理或严谨的验证活动保证设计/实现满足规约，这是净室的核心思想
- 统计控制下的增量式开发：用受控的增量迭代来降低风险、便于度量与改进，但其作用是过程组织方式，不是核心
- 基于函数的规范和设计、盒结构（黑盒/状态盒/明盒）：是实现正确性验证的工程手段与设计方法
- 统计测试和软件认证：用于基于使用剖面（Usage Profile）的可靠性评估与发布认证，属于度量与认证阶段
因此，净室软件工程的核心是正确性验证，选 C。
17
知识点： 软件工程 > 信息系统开发方法 > 统一过程（UP / RUP）
答案：A
解析：
统一过程（Unified Process）把一个项目划分为四个阶段（每一轮遍历四阶段可形成一代产品/一代软件），标准表述为：
| 阶段 | 常见名称 | 要点 |
|---|---|---|
| 初始（初启） | Inception | 明确产品愿景与业务模型，界定系统范围 |
| 细化（精化） | Elaboration | 确定系统架构，制定工作计划与资源要求 |
| 构造 | Construction | 完成剩余构件与功能，集成产品并做详细测试 |
| 移交 | Transition | 确保对最终用户可用，β 测试，形成发布版本 |
选项 B、C 是经典瀑布式活动划分；D 中"初始分析"等表述不规范。故选 A：初始、细化、构造和移交。
18
知识点： 软件工程 > 信息系统开发方法 > RUP 核心工作流
答案：B
解析：
RUP 的 6 个核心过程工作流：业务建模、需求、分析与设计、实现、测试、部署。
3 个核心支持工作流 ：配置与变更管理、项目管理、环境。
题干问"不属于 核心过程工作流的"，项目管理 属于支持工作流，因此选 B。
易错点：勿把"商业建模/业务建模"当成支持工作流------它属于 6 个核心过程工作流之一。
19
知识点： 软件工程 > 开发模型 > 基于构件的软件工程（CBSE）
答案：D
解析：
用于 CBSE 的构件通常强调：可组装性 （通过公开接口交互）、可部署性 （二进制交付、在构件平台上独立运行）、文档化 （便于选型与使用）、独立性 （可独立组装部署，依赖须显式声明）、标准化（符合统一构件模型）等。
构件恰恰应支持在接口契约下的替换与升级 ，"不可替代"与复用、演进的初衷相反，因此不是 CBSE 构件应具备的特征，选 D。
20
知识点： 软件工程 > 开发模型 > 螺旋模型
答案：D
解析：
螺旋模型在快速原型基础上扩展，将多轮迭代组织为螺旋式推进；每一圈（每个阶段）通常包含四步：
- 目标设定：本阶段需求分析，确定目标、过程与产品约束，制定详细管理计划
- 风险分析：识别备选方案风险，制定规避措施
- 开发和有效性验证：按风险结论选用开发模型，建造原型/产品并验证
- 评审：评估是否进入下一圈；若继续，制订下一阶段计划
每迭代一圈螺旋外扩，产出更接近目标的系统版本；否则可能提前终止。选项 D 与教材表述一致。
32
知识点： 软件工程 > 信息系统开发方法 > 面向服务（SO）
答案：B
解析：
面向服务的方法 通常给出三层抽象（自底向上）：
- 操作（Operation） ：最底层，表示单一逻辑工作单元的事务（类似 OO 中的方法），如对持久数据的读/写/改
- 服务（Service） ：中间层，对若干操作的逻辑分组
- 业务流程（Business Process） ：最高层，为达成业务目标而编排服务的长期活动集合
题干"三个主要抽象级别 ""最低层操作 = 单个逻辑单元 "与上述 SO 分层一致，选 面向服务法（B）。
对照记忆： 结构化方法强调 SA/SD/SP 与自顶向下模块化；面向对象以对象/类为中心；原型法强调快速迭代澄清需求。
二、需求工程与结构化分析
3
知识点： 软件工程 > 需求工程 > 需求变更管理
答案：B
解析：
需求变更管理通常遵循"提出---澄清---评估---决策---实施---验证/发布"的链路。题干强调的是把"变更建议"经过充分分析后，形成"明确的需求变更提议"，本质上是从"模糊建议/问题"到"可评审、可评估、可执行的变更描述"的转化步骤。
- A 识别出问题：属于变更的来源发现阶段，只是提出线索，还没有形成明确的变更提议
- B 问题分析和变更描述：对建议进行深入分析，澄清问题边界、目标、影响范围与期望结果，并把它写成可理解、可验证的变更描述，这是把建议转为明确提议的关键步骤
- C 变更分析和成本计算：在变更提议已明确后，进一步做影响分析与成本/进度评估，为决策提供依据
- D 变更实现：在审批通过后执行落地，不负责把建议转化为提议
因此选 B。
9
知识点： 软件工程 > 需求工程 > 结构化分析（SA）> 数据字典
答案：C
解析：
结构化分析常用三类模型表达系统：
- 数据模型：常用实体-联系图（E-R 图）表达实体、关系、属性
- 功能模型：常用数据流图（DFD）表达数据输入、处理、输出的流动过程
- 行为模型：常用状态转换图表达状态及状态变化事件
这三类模型里贯穿全局、用来统一定义数据项/数据结构/数据流含义的"核心"，是数据字典。数据字典把模型中出现的数据对象与控制信息做精确定义，保证分析与设计阶段对"数据含义"理解一致，因此选 C。
三、软件设计（耦合与设计活动）
16
知识点： 软件工程 > 软件设计 > 模块耦合度
答案：D
解析：
模块间耦合按从弱到强（从低到高）的常见排序如下（与多数教材、教辅一致）：
- 非直接耦合：模块之间无直接关系，联系完全由主模块的控制与调用实现
- 数据耦合 ：通过参数表传递简单数据项
- 标记耦合 ：通过参数表传递记录/复杂数据结构
- 控制耦合 ：所传信息中含有用于控制接收方内部逻辑的成分（本题"第四位"）
- 外部耦合 ：多模块访问同一全局简单变量（非经参数传递）
- 公共耦合 ：多模块访问同一公共数据环境（全局数据结构、共享通信区、公共内存区等）
- 内容耦合（最强）：如直接访问他模块内部数据、非正常入口转入他模块、程序代码重叠、一模块多入口等
因此从低到高第 4 位是控制耦合，选 D。
速记： 非数标控，外公内（非直接→数据→标记→控制→外部→公共→内容）。
21
知识点： 软件工程 > 软件设计 > 设计活动划分
答案：B
解析：
软件设计常归纳为四类相互关联的活动（与结构化/经典教材体系一致）：
| 活动 | 含义概要 |
|---|---|
| 数据设计 | 将分析模型转化为数据结构定义，利于模块划分、降低过程复杂性 |
| 体系结构/结构设计 | 定义系统主要部件及其关系 |
| 接口设计（含人机界面） | 软件内部、软件与 OS、软件与用户之间的交互方式 |
| 过程设计 | 把结构部件落实为可实现过程：各部件内算法与内部数据结构，及流程图/伪代码等表达 |
题干已给出"软件结构设计、人机界面设计"，第一空 为数据设计，选 B。易错：用例设计偏需求/分析侧，不应填于此。
22
知识点： 软件工程 > 软件设计 > 设计活动划分
答案：D
解析：
四类设计活动为：数据设计、结构设计、接口/人机界面设计、过程设计 。前三项已在题干预设，第四项为过程设计（亦称构件级设计等表述），选 D。易错：接口设计已在题干以"人机界面设计"体现，勿再选 A。
四、面向对象设计原则（OOD）
26
知识点： 系统设计 / 软件工程 > 面向对象设计 > OOD 原则
答案：A
解析：
开闭原则 ：对扩展开放、对修改关闭------在不改动既有代码的前提下，通过扩展（如新增子类、新实现）为系统增加新行为，契合题干"扩展已有系统并为之提供新的行为"。故第 26 空选 开闭。
延展（常见 OOD 原则速记）：
| 原则 | 要点 |
|---|---|
| 开闭 | 扩展开放、修改关闭 |
| 里氏替换 | 子类可替换父类且不破坏多态语义 |
| 依赖倒置 | 高层与底层均依赖抽象；面向接口编程，而非面向实现 |
| 接口隔离 | 不强迫客户依赖其不用的方法 |
| 最小知识（迪米特法则） | 尽量减少对象间交互，降低耦合 |
27
知识点： 系统设计 / 软件工程 > 面向对象设计 > OOD 原则
答案：B
解析：
依赖倒置原则 强调：高层模块不应依赖低层模块的具体实现，二者应依赖抽象（接口/抽象类）；编程时应针对接口（抽象）编程，而不是针对具体实现编程 。题干表述与此完全一致，选 B。易错：接口隔离强调"接口拆分、不强迫依赖无用方法"，与"对实现编程"的对比不是同一侧重点。
五、设计模式
23
知识点： 软件工程 > 设计模式 > GoF 分类
答案：C
解析：
- 创建型模式 ：描述怎样创建对象，把对象的创建与使用分离，抽象"实例化与组合"过程（单例、原型、工厂方法、抽象工厂、构建器等）
- 结构型模式：怎样组合类/对象形成更大结构（代理、适配器、桥接、装饰、外观、享元、组合等）
- 行为型模式：对象怎样协作完成职责（模板方法、策略、命令、职责链、状态、观察者等）
题干强调"对实例化过程的抽象""创建、组合"的封装，属创建型模式，选 C。
34
知识点： 软件工程 > 设计模式 > GoF 分类
答案：C
解析：
- 创建型（5） ：单例、原型、工厂方法、抽象工厂 、构建器等------关注对象创建与使用解耦
- 结构型（7） ：代理、适配器 、桥接、装饰、外观、享元、组合等------关注组合成更大结构
- 行为型（11） ：模板方法、策略、命令、职责链、状态 、观察者 、中介者、迭代器、访问者、备忘录、解释器等------关注协作与职责分配
题干要创建型 ，只有 抽象工厂 符合，选 C。
六、UML 与面向对象分析
10
知识点： 软件工程 > 面向对象基础 > UML 基本概念
答案：B
解析：
UML 的建模元素（事物）通常分为：结构事物、行为事物、分组事物、注释事物。其中行为事物是 UML 模型的动态部分，用来描述系统在时间与空间上的动作与行为，因此选 B。
11
知识点： 软件工程 > 面向对象基础 > UML 行为事物
答案：A
解析：
UML 的主要行为事物通常归纳为两类：交互（对象之间为达成目标而进行的一系列消息交换）与状态机（对象在不同状态之间的转换以及触发事件），因此选 A。
12
知识点： 软件工程 > 面向对象基础 > 分析类（边界类/控制类/实体类）
答案：D
解析：
面向对象分析中常把分析类分为三类：
- 实体类：保存业务数据与业务规则，通常可持久化（例如学员、课程、订单）
- 边界类：系统与外部交互的"边界"，例如页面、窗口、API 接口、适配器
- 控制类：协调用例流程，把边界类的输入组织起来驱动实体类完成业务
题目中的"学员类""课程类"主要用于表达与保存业务对象信息，属于实体类，因此选 D。
13
知识点： 软件工程 > 面向对象基础 > 分析类（边界类/控制类/实体类）
答案：B
解析：
"窗口"位于系统与用户交互的交接处，用来接收输入、展示输出，属于边界类，因此选 B。
24
知识点： 软件工程 > UML > 用例图关系
答案：C
解析：
用例图中的关系需区分主体：
- 用例---用例 ：常见 include（包含） 、extend（扩展） ，有时用例之间还可 泛化
- 参与者---用例 ：关联
- 参与者---参与者 ：可存在 泛化（继承） （特殊参与者继承一般参与者），题干问"参与者之间"，选 继承/泛化 表述，对应选项 C
包含、扩展多用于用例之间，勿与参与者关系混淆。
25
知识点： 软件工程 > UML > 人机界面建模
答案：A
解析：
在界面设计建模的常见约定中：
- 类图：描述界面元素（如窗体、控件）及其静态结构与关系
- 顺序图 ：描述用户与界面、界面之间的交互跳转与时间次序，体现界面流转
故"界面元素 + 跳转关系"分别对应类图 与顺序图，选 A。
35
知识点： 软件工程 > UML 2 图分类
答案：B
解析：
- 部署图 ：描述运行期物理处理节点 的配置及驻留其上的构件等，给出部署视图
- 制品图 ：描述系统在物理介质上的制品 （文件、数据库、可执行体等"物理比特"集合）及其关系，体现物理实现结构 ，并常说明制品实现了哪些类/构件；常与部署图配合使用
用例图、状态图不描述物理文件级结构；部署图题干已作为"一起使用"的另一类图出现，不能重复选 D。故选 制品图（B）。
附录（UML 2 十四种图速览）： 类、对象、构件、组合结构、用例；顺序、通信、定时、交互概览；状态、活动；部署、制品 ；包图等。题目考查物理结构 + 与部署图联用，对应制品图。
七、软件测试与调试
5
知识点： 软件工程 > 软件测试 > 静态测试
答案：C
解析：
静态测试的本质特征是"不运行程序"，通过人工检查或工具静态分析来发现缺陷，常见形式包括桌前检查（Desk Check）、走查（Walkthrough）、代码审查/评审（Review/Inspection）等。
选项辨析：
- A 边界值分析：典型黑盒动态测试方法，需要执行程序并用边界输入验证
- B 错误推测法：常用于动态测试中的经验型用例设计方法，依赖运行验证结果
- C 桌前检查：人工逐行/逐段检查代码或文档，不运行程序，属于静态测试
- D 逻辑覆盖测试：白盒动态测试，需要执行代码并统计覆盖率
因此选 C。
6
知识点： 软件工程 > 软件测试 > 自动化测试脚本
答案：B
解析：
"通过录制用户操作直接生成的脚本"对应的是录制回放（Record & Playback）产生的线性脚本：脚本把一次测试过程中的点击、输入、校验等操作按时间顺序串起来执行，结构简单、维护成本相对较高（界面变动就容易失效）。
其他选项不符合"录制直接生成"的特点：
- 结构化脚本：通常引入分支、循环、函数/过程等结构化设计思想，需要人为抽象与重构
- 共享脚本：强调可被多个用例复用或被其他脚本调用，通常来自模块化/函数化抽取
- 数据驱动脚本：把测试数据与脚本逻辑分离，通过多组数据驱动同一套测试流程
因此选 B。
7
知识点： 软件工程 > 软件测试 > 白盒测试覆盖准则
答案：D
解析：
白盒测试覆盖准则通常从弱到强为：语句覆盖 → 判定/分支覆盖 → 条件覆盖/判定-条件覆盖/条件组合覆盖 → 路径覆盖（概念上最强）。
路径覆盖要求"程序中每条可执行路径至少执行一次"，覆盖范围包含各判定结果组合，因此测试强度最高。实际工程中由于路径数可能爆炸（尤其存在循环时），常用可行的覆盖准则（如分支覆盖/条件覆盖）替代"完整路径覆盖"，但题目问"最高"，应选路径覆盖。
8
知识点： 软件工程 > 软件测试 > Web 测试与其它测试
答案：B
解析：
- A：Web 系统测试与其它系统测试在本质上测试内容并非"完全不同"，只是测试重点不同；Web 常强调链接、兼容性、表单、界面等，但测试目标仍是功能、性能、安全等
- B：链接测试的一个重要目标是避免"孤立页面"（没有任何入口链接可达的页面），保证站点结构完整可达，因此正确
- C：回归测试的目的在于变更后验证受影响部分及相关功能未被破坏，不限定在集成测试阶段；"增量组装"是集成策略之一，但不是回归测试的定义或特征
- D：AB 测试用于对比不同版本在用户行为指标上的效果评估；金丝雀发布是灰度发布策略，二者概念不同
因此选 B。
33
知识点： 软件工程 > 软件测试 > 测试与调试区别
答案：A
解析：
测试与调试的差别可概括为：
| 维度 | 测试 | 调试 |
|---|---|---|
| 目的 | 发现错误 | 定位并修正错误（修改程序） |
| 先后 | 一般先测试、后调试（先发现再追查修复） | 在测试等环节发现问题后的后续活动 |
| 条件与过程 | 多在已知前提 下按预定用例与流程 执行，结果可预期、过程与进度可事先规划 | 往往从不确定 的现场出发，路径与耗时难以事先完全预计 |
选项辨析：
- A ：调试在测试之后（或紧随缺陷发现），二者目的、方法与思路不同------正确
- B ：把"已知/未知、可预知"说成调试与测试的关系，说反了（通常测试更可计划、调试更探索性）
- C ：找出错误 主要是测试 的目标；调试更强调定位原因与修复
- D ：测试过程与周期可以规划与描述
故选 A。
八、系统演进、切换与维护
14
知识点： 软件工程 > 系统运行与维护 > 遗留系统演化策略
答案：C
解析：
遗留系统常见演化策略可以概括为四类：
- 淘汰：完全替换旧系统（旧系统价值低或已不适配业务）
- 继承：新系统完全兼容旧系统模型，并行运行一段时间后逐步切换
- 改造：保留旧系统价值与基础，在原系统上增强功能、改造数据模型或架构
- 集成：面向"信息孤岛"，通过集成把多个系统打通协同
题干强调"技术含量较高、生命力强、业务价值高，且基本能满足运作与决策支持"，说明旧系统本身仍然值得保留并增强，适合采用改造策略，因此选 C。
15
知识点： 软件工程 > 系统运行与维护 > 遗留系统演化策略
答案：B
解析：
题干的关键特征是：
- 新系统需要完全兼容旧系统的功能模型与数据模型
- 为保证连续性，新老系统并行运行一段时间，再逐步切换
这正是继承策略的典型做法，因此选 B。
30
知识点： 软件工程 > 系统切换 / 新旧系统转换
答案：A
解析：
常见转换方式对比：
| 方式 | 含义 | 风险 | 成本/复杂度 |
|---|---|---|---|
| 直接转换 | 试运行无误后立即停用旧系统、启用新系统 | 高 | 低 |
| 并行转换 | 一段时期内新旧并行，新系统验证稳定后再切换 | 低 | 高（双轨运行） |
| 分段（阶段）转换 | 直接转换与并行转换等组合的折中 | 中等 | 中等 |
| 分块转换 | 多数教材中非标准分类，常作干扰项 |
题干要求"风险降到最低 "，应选 并行转换（A）。
31
知识点： 软件工程 > 可维护性 / 软件维护类型
答案：A
解析：
软件交付运行后的维护常分为四类（题干强调发现与纠正错误/缺陷）：
| 类型 | 典型含义 |
|---|---|
| 正确性维护 | 识别、纠正软件中的错误与缺陷（测试无法穷尽所有错误，上线后仍可能暴露） |
| 适应性维护 | 因外部环境、数据环境等变化而修改，以保持可用 |
| 完善性维护 | 在运行中按新需求扩充功能、改善性能等 |
| 预防性维护 | 为应对未来软硬件变化，主动增加预防性能力，通用化改造等，降低将来失效风险 |
"维护"一词泛指运行期各类改动；专门针对缺陷纠错 的是正确性维护，选 A。
九、逆向工程
28
知识点： 软件工程 > 逆向工程 > 抽象级别
答案：C
解析：
逆向工程常见四个抽象级别（由低到高、由实现到业务含义）：
| 级别 | 含义概要 | 典型信息/产物 |
|---|---|---|
| 实现级 | 贴近源码与实现细节 | 抽象语法树、符号表、过程的设计表示等 |
| 结构级 | 分量间依赖与组织 | 调用图、结构图、程序与数据结构等 |
| 功能级 | 程序段功能及段间关系 | 数据流/控制流模型等 |
| 领域级 | 程序实体与业务/应用领域概念的对应 | 如 ER 模型等 |
题干强调"程序分量或实体与应用领域概念 的对应"，属领域级，选 C。
29
知识点： 软件工程 > 逆向工程 > 恢复方法
答案：D
解析：
不同恢复方法大致对应的抽象层次（与多数教辅一致）：
- 用户指导下的搜索与变换 ：多用于导出实现级、结构级
- 变换式方法 ：多用于实现级、结构级、功能级
- 铅板恢复法 （教材亦作样板/套路恢复）：多用于实现级、结构级
- 基于领域知识的方法 ：借助领域语义与知识，用于导出功能级与领域级信息
题干问"导出功能级和领域级 "，选 基于领域知识的方法，对应 D。
补充：常见软件开发反模式（速记）
- 过早优化：没数据就先上复杂方案；先可观测再定位瓶颈再优化
- 单车车库：小事争论太久；小事默认规则，大事时间盒决策
- 分析瘫痪：只讨论不落地；用最小实验/灰度拿真实反馈
- 上帝类：一个类什么都管；按职责/变化原因拆分并提升可测试性
- 新增类恐惧症：不敢拆导致大类堆分支；用高内聚低耦合衡量而非类数量
- 内部平台效应：重造基础设施轮子；优先复用成熟组件，必要自研要有退出机制
- 魔法数/字符串：字面量散落；用常量/枚举/配置表达语义并按领域归类
- 数字管理：指标绑架决策；用指标辅助决策，主指标配约束指标，防止"刷指标"
- 幽灵类：空壳转发增加层级；只保留真正增加价值的抽象（约束/屏蔽变化/转换/边界）