信息系统管理工程师（中级）备考笔记 · 第六章：软件开发过程管理

考试科目：信息系统管理工程师（中级）—— 计算机技术与软件专业技术资格（水平）考试

章节定位：本章是信息系统管理工程师在"软件开发过程"维度的专业考查，上承IT服务管理（第5章），下启系统集成实施管理（第7章），内容量大、概念多。

预估分值：上午 5~10 分（以概念辨析题为主，部分涉及工具理解）

参考来源：中国计算机技术职业资格网 · 希赛网-信息系统管理工程师

更新日期：2026-06-30

教材对照：《信息系统管理工程师教程（第2版）》第6章（2024年9月版）

一、章节总览

第六章「软件开发过程管理」围绕软件从需求到交付的全过程展开，内容涵盖开发过程模型、需求工程、软件设计、测试、部署交付以及过程能力成熟度等。本章知识点多且分散，以记忆和理解型为主。

知识体系结构

小节	内容	考试权重
6.1 基本概念	软件开发活动与职责、5种常见过程模型	⭐⭐⭐
6.2 软件需求	需求层次、QFD、需求获取/分析(SADFD/OOA)、SRS、需求确认/变更/跟踪	⭐⭐⭐⭐⭐
6.3 软件设计	结构化设计(SD)、面向对象设计(OOD)、UML、设计模式	⭐⭐⭐⭐
6.4 软件实现	编码、测试（方法、类型、面向对象测试）	⭐⭐⭐⭐
6.5 部署交付	软件部署、传统交付 vs 持续交付/部署、CI/CD	⭐⭐
6.6 全过程管理	配置管理、质量管理、工具管理、开源管理	⭐⭐⭐
6.7 软件过程能力成熟度	CSMM框架（能力域+成熟度等级）	⭐⭐
6.8 软件工厂	概念、与传统开发对比、建设方法	⭐

二、6.1 基本概念

2.1 活动与职责

软件开发过程是指用于开发和维护软件及其相关产品的一系列活动、方法、实践和革新。

一般过程活动： 1. 需求分析 → 与客户沟通，分析项目目标/范围/时间/成本/质量 2. 系统设计 → 设计架构、接口、数据模型、算法 3. 编码 → 根据设计文档编写代码 4. 测试 → 确保功能正确、性能良好、安全稳定 5. 部署 → 部署到生产环境，实施和培训 6. 维护 → 监控、备份、恢复、更新

管理工程师主要职责：

职责	说明
项目计划	确定目标、范围、时间、成本、质量要求，制定项目计划
项目组织	确定组织结构，分配资源，明确团队成员职责
项目执行	根据计划和组织结构实施各项活动
项目控制	监控进度和性能，出现偏差时采取纠正措施
项目结束	完成所有活动，交付产出，评估绩效

2.2 常见过程模型 ★★★

五种常见开发过程模型：瀑布模型、迭代模型、增量模型、螺旋模型、敏捷模型。

模型	核心思想	优点	缺点	适用场景
瀑布模型	线性顺序阶段：需求→设计→编码→测试→部署→维护	易于管理，阶段输入输出明确	不适用需求变化，后期发现问题代价大	需求稳定、项目简单
迭代模型	重复迭代，每次迭代产出可运行系统	灵活应对需求变化，尽早发现问题降低风险	需要更多管理和控制，文档较多	需求不稳定、项目复杂
增量模型	按增量逐步交付功能，先核心功能后扩展	逐步交付功能，尽早发现和解决问题	需要确定全部初始需求	需求不稳定、项目复杂
螺旋模型	迭代+风险分析，每轮包含4个象限	通过风险分析降低风险	管理复杂，文档多	需求不稳定、高风险项目
敏捷模型	强调灵活性和快速响应变化，Scrum/Kanban/XP	灵活应对变化，团队协作强，持续改进	需要高自我管理能力，不适合大型项目	需求不稳定、时间敏感

常见敏捷方法： - Scrum：冲刺(Sprint)2~4周，Sprint Backlog → Sprint Review → Sprint Retrospective - Kanban：看板图(ToDo→InProgress→Done)，可视化流程管理 - 极限编程(XP)：测试驱动开发(TDD)、持续集成、代码重构

💡 考试提示：常给出场景描述让选择最合适的开发模型，注意辨析各模型的优缺点和适用场景。

三、6.2 软件需求 ★★★★★

软件需求是指用户对系统在功能、性能和设计约束等方面的期望。

3.1 需求的层次 ★★

层次	说明	来源
业务需求	组织或用户高层次目标要求，回答"为什么"	投资人、客户管理层、产品策划
用户需求	用户具体目标或系统必须完成的任务	用户访谈、问卷调查
系统需求	从系统角度说明需求，含功能/非功能/约束	需求分析后整理

系统需求细分： - 功能需求（行为需求）：系统必须实现的功能 - 非功能需求：系统具备的属性或品质（性能、易用性、可维护性等） - 约束：对设计和构造的限制（设计约束、过程约束）

3.2 质量功能部署（QFD）★

QFD是一种将用户要求转化成软件需求的技术，将需求分为三类：

类型	说明	特点
常规需求	用户认为系统应做到的	实现越多越满意
期望需求	用户默认应具备但未明确描述	未实现则不满意
意外需求（兴奋需求）	用户范围外的功能特性	实现更高兴，不实现不影响决策

3.3 需求获取 ★

常见方法：用户访谈、问卷调查、采样、情节串联板、联合需求计划。

💡 考试提示：需求获取是否科学准确直接影响项目成败，遗漏或理解错误的需求通常在开发后期才被发现，代价巨大。

3.4 需求分析 ★★★★

好的需求应具备：无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性。

结构化分析（SA）★★★

核心：数据字典 + 三层模型

模型	表达工具	用途
数据模型	实体关系图(E-R图)	描述实体、属性及关系
功能模型	数据流图(DFD)	从数据传递和加工角度描述系统功能
行为模型（状态模型）	状态转换图(STD)	描述状态及状态转换事件

DFD建模方法的4种基本元素：

元素	说明
数据流	箭头描述数据流向
处理/加工	矩形框，对数据进行加工和转换
数据存储	存储数据的地方
外部项	系统数据的提供者或使用者（圆角框或平行四边形）

DFD建模步骤：明确目标→建立顶层DFD→构建第一层分解图→开发层次结构图→检查确认

数据字典：描述数据的数据项、数据结构、数据流、数据存储、处理逻辑等，是对DFD中各个元素的详细说明。

数据字典的组成：

部分	说明
数据项	不可再分的数据单位，含名称、类型、长度、取值范围等
数据结构	数据之间的组合关系，可由数据项或数据结构组成
数据流	数据结构在系统内的传输路径
数据存储	数据结构停留或保存的地方
处理过程	功能块的说明性信息

面向对象分析（OOA）★★

5个层次：主题层、对象类层、结构层、属性层、服务层 5个活动：标识对象类、标识结构、定义主题、定义属性、定义服务

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

OOA基本步骤： 1. 确定对象和类 2. 确定结构（泛化-特化关系、整体-部分关系） 3. 确定主题 4. 确定属性 5. 确定方法

3.5 需求规格说明书（SRS）★★

SRS是需求分析的最终结果，是整个开发工作的基础。按GB/T 8567规定，SRS应包括：

范围：标识、用途、历史、投资方、运行现场等
引用文件
需求：主体部分，详细描述状态/方式、功能/外部/内部接口、保密性、环境、资源、质量因素等
合格性规定：定义演示、测试、分析、审查等合格性方法
需求可追踪性：双向追踪
尚未解决的问题
注解：背景信息、词汇表、原理
附录

💡 考试提示：SRS是软件开发过程中最重要的文档之一，任何规模和性质的软件项目都不应缺少。

3.6 需求确认 ★

需求确认（验证）的核心： - SRS正确描述了预期的系统行为和特征 - 需求完整且高质量 - 所有表示一致 - 为设计、实现、测试提供足够基础

通过需求评审和需求测试来进行验证。

3.7 需求变更 ★★

变更控制过程：

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

变更控制委员会（CCB）： - 项目所有者权益代表，负责裁定接受哪些变更 - 是决策机构不是作业机构 - 成员包括：产品/计划管理、项目管理、开发、测试/QA、市场/客户代表等

CCB决策三要素： 1. 制定决策 → 权衡利弊（利：节省资金、客户满意度；弊：开发费用增加、交付推迟） 2. 交流情况 → 更新请求状态 3. 重新协商约定 → 与管理部门和客户重新协商

💡 考试提示：CCB的角色定位（决策机构而非作业机构）和变更控制过程的步骤可能考查。

3.8 需求跟踪 ★

需求跟踪提供了从需求到产品实现全过程范围的明确查询能力。目的：建立与维护需求-设计-编程-测试之间的一致性。

跟踪方式	说明
正向跟踪	检查SRS每个需求是否在后续工作成果中找到对应点
逆向跟踪	检查设计文档、代码、测试用例等是否能在SRS中找出处
双向跟踪	正向+逆向，通过需求跟踪矩阵实现

四、6.3 软件设计 ★★★★

软件设计解决"怎么做"的问题，是需求的延伸与扩展，也是系统实施的基础。

4.1 结构化设计（SD）★★★

SD是一种面向数据流的方法，以SRS、DFD、数据字典为基础，是自顶向下、逐层分解、逐步求精和模块化的过程。

两个阶段：

阶段	任务	产出
概要设计（总体结构设计）	划分模块，确定功能、接口和调用关系	系统结构图(SC)
详细设计	设计各模块算法、局部数据结构	详细设计文档

模块化设计核心概念

耦合（模块间联系程度，从低到高）：

类型	描述	强度
非直接耦合	无直接关系，通过上级模块调用	最弱
数据耦合	通过参数表传递简单数据	↑
标记耦合	通过参数表传递记录等复杂信息	↑
控制耦合	传递的信息含控制模块内部逻辑的信息	↑
通信耦合	共享输入或输出	↑
公共耦合	多个模块访问同一公共数据环境	↑
内容耦合	一个模块直接访问另一个模块内部	最强

内聚（模块内部联系的紧密程度，从高到低）：

类型	描述	强度
功能内聚	完成单一功能，缺一不可	最强
顺序内聚	处理元素相关且顺序执行	↑
通信内聚	所有处理在同一数据结构区域上	↑
过程内聚	处理元素相关且按特定次序执行	↑
时间内聚	任务必须在同一时间间隔执行	↑
逻辑内聚	完成逻辑上相关的一组任务	↑
偶然内聚	完成无关系或松散关系的任务	最弱

💡 核心原则：高内聚、低耦合——耦合度低则模块独立，可单独开发维护；内聚度高则模块可理解性和维护性强。

详细设计工具

工具类型	具体工具
图形工具	程序流程图、PAD图、NS流程图（盒图）
表格工具	判定表/决策表
语言工具	PDL（伪码/结构化语言）

4.2 面向对象设计（OOD）★★

OOD基本原则：

原则	说明
单一职责原则	一个类仅有一个引起变化的原因
开闭原则	对扩展开放，对修改封闭
里氏替换原则	子类可替换父类
依赖倒置原则	依赖抽象而非具体实现
接口隔离原则	多个专门接口优于单一总接口
组合重用原则	尽量用组合而非继承达到重用
迪米特原则	一个对象应对其他对象了解最少

类的三种类型：

类类型	特点	属性/方法	举例
实体类	映射需求中的实体，通常为永久性	一定有属性，不一定有操作	学员类、课程类
控制类	控制用例工作，行为有协调性	一般没有属性，一定有方法	身份验证器
边界类	封装内外流动的信息/数据流	可既有属性也有方法	窗口、报表、通信协议接口

4.3 统一建模语言（UML）★★

UML支持从需求分析开始的软件开发全过程。

UML结构三部分：构造块、规则、公共机制

UML的事物（4种）： - 结构事物：类、接口、协作、用例、活动类、构件、节点（静态部分） - 行为事物：交互（消息交换）、状态机（动态部分） - 分组事物：包（组织单元） - 注释事物：解释部分

UML的关系（4种）：

关系	说明
依赖	一个事物变化影响另一个
关联	对象之间有联系
泛化	一般-特殊关系
实现	一个类指定由另一个类执行的契约

UML 2.0的14种图（需要掌握的重点）：

结构图（静态）：

图	说明
类图	描述类、接口、协作及关系，最常用
对象图	描述对象及关系，类图的实例快照
构件图	封装类及接口、端口、内部结构
组合结构图	描述类的内部构造
包图	描述模型分解的组织单元和依赖
部署图	描述运行时处理节点及构件配置
制品图	描述系统的物理结构（文件、数据库等）

行为图（动态）：

图	说明
用例图	用户与系统交互的最简表示，最基本的需求分析模型
顺序图（序列图）	强调消息的时间次序
通信图	强调收发消息的对象的结构组织
定时图（计时图）	描述对象随时间变化的状态/值
状态图	描述基于事件反应的动态行为
活动图	展示计算内部的控制流和数据流
交互概览图	活动图和顺序图的混合物

UML的5个系统视图：

视图	说明
逻辑视图（设计视图）	系统静态结构和动态行为，侧重点在"如何得到功能"
进程视图	可执行线程和进程，描述并发与同步结构
实现视图	对物理代码文件和构件建模
部署视图	构件到物理节点的映射和分布结构
用例视图	最基本的需求分析模型，从外部角色视角展示功能

4.4 设计模式 ★

分类	目的	常见模式
创建型模式	主要用于创建对象	工厂方法、抽象工厂、原型、单例、建造者
结构型模式	处理类或对象的组合	适配器、桥接、组合、装饰、外观、享元、代理
行为型模式	描述类/对象的交互和职责分配	职责链、命令、解释器、迭代器、中介者、备忘录、观察者、状态、策略、模板方法、访问者

五、6.4 软件实现 ★★★★

5.1 软件编码

程序设计语言选择：编码是把设计结果翻译成计算机可识别的形式，语言特性影响程序的可读性、可测试性和可维护性。

程序设计风格4个方面：源程序文档化、数据说明、语句结构、输入/输出方法

程序复杂性度量：定量度量可估算故障数量和工作量，比较不同设计/算法的优劣。

编码效率：程序效率、算法效率、存储效率、I/O效率

软件调试策略三类：蛮力法、回溯法、原因排除法

5.2 软件测试 ★★★

测试目的：发现软件错误（缺陷），验证软件是否满足规定的质量要求。

测试方法

方法	说明	细分
静态测试	不运行程序，分析源程序语句、结构、过程	桌前检查、代码走查、代码审查（可发现30%~70%逻辑设计和编码错误）
动态测试	运行程序，比较实际结果与预期结果	白盒测试、黑盒测试

白盒测试（结构测试）：

主要用于单元测试
将程序看作透明白盒，按内部逻辑设计测试用例
最常用技术：逻辑覆盖
覆盖标准：语句覆盖 → 判定覆盖 → 条件覆盖 → 条件/判定覆盖 → 条件组合覆盖 → 修正条件/判定覆盖 → 路径覆盖

黑盒测试（功能测试）：

将程序看作不透明黑盒，根据SRS设计测试用例
常用方法：等价类划分、边界值分析、判定表、因果图、状态图、随机测试、猜错法、正交试验法

测试类型

测试类型	说明	依据
单元测试	测试独立编译/汇编的模块	详细设计说明书
集成测试	测试组装模块，发现接口相关问题	概要设计文档
确认测试	验证功能/性能是否符合用户需求	SRS
系统测试	在真实环境下测试完整系统	系统/子系统设计文档
配置项测试	检验软件配置项与SRS一致性	SRS
回归测试	变更后验证原有的正确功能不受影响	—

💡 辨析提示：单元测试依据详细设计、集成测试依据概要设计、系统测试是真实环境全面测试、回归测试是变更后的验证。

面向对象测试

OO系统的三个特征给测试带来困难： - 封装性 → 需考虑信息隐蔽和对象状态与测试序列 - 继承性 → 需考虑对测试充分性的影响及误用错误 - 多态性 → 需考虑动态绑定对测试充分性的影响及抽象类测试

六、6.5 部署交付 ★★

6.1 软件部署

软件部署是软件生命周期的重要环节，通过配置、安装和激活保障软件后续运行。

部署模式：

模式	适用场景
面向单机软件部署	操作系统之上的单机软件
集中式服务器应用部署	用户访问量小（500人以下）
基于微服务的分布式部署	用户访问量大、并发性高的云原生应用（需容器+DevOps）

6.2 传统软件交付 vs 持续交付

传统交付流程：业务想法 → 开发 → 测试 → 用户使用 → 运维 存在问题：需求文档沟通效率低、测试工作量递增、运维排期被挤占

持续交付是一系列开发实践方法，确保代码快速、安全地部署到生产环境。

持续交付优势：

缩短提交到上线时间，降低部署风险
自动快速反馈，及时发现和修复缺陷
软件生命周期内保持可部署状态
简化部署步骤，版本更清晰
交付过程可靠、可预期、可视化

核心指标：一行代码改动到部署上线的耗时

6.3 持续部署

容器技术（Docker + Kubernetes）是目前最流行的部署技术。

部署原则： - 部署包全部来自统一存储库 - 所有环境使用相同部署方式和脚本 - 流程编排阶梯式晋级，设检查点支持回滚 - 仅通过流水线改变生产环境，防止配置漂移 - 不可变服务器

部署层次：Build → Ship → Run

部署方式：

方式	说明
蓝绿部署	准备新旧两个版本，通过域名解析切换，快速回退
金丝雀部署	先让少量用户使用新版本，验证无误后逐步全量推送

新趋势：工作职责转变（开发人员扩展交付/部署）、云计算基础设施普及、研发运维融合

七、6.6 全过程管理关注 ★★★

7.1 软件配置管理（SCM）★★

SCM是一种标识、组织和控制修改的技术，核心内容包括版本控制和变更控制。

版本控制： - 追踪文件变更（什么人、什么时间、改了什么） - 支持并行开发，通过分支与合并解决冲突

变更控制： - 目的不是阻止变更，而是管理变更，确保有序进行 - 变更来源：外部（客户需求）和内部（错误修复）

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

7.2 软件质量管理 ★★

软件质量：软件与明确和隐含定义的需求相一致的程度。

影响软件质量的三个因素： - 产品运行：正确性、健壮性、效率、完整性（安全性）、可用性、风险 - 产品修改：可理解性、可维护性、可测试性、灵活性 - 产品转移：可移植性、可复用性、互运行性

软件质量保证（SQA）： - 建立有计划、有系统的方法，向管理层保证标准、步骤和方法被正确采用 - 关注点：预防缺陷而不是检测缺陷 - 以独立审查方式从第三方角度监控

SQA主要任务： 1. SQA审计与评审（软件工作产品、工具设备） 2. SQA报告（与高级管理者有直接沟通渠道） 3. 处理不符合问题

7.3 工具管理 ★

工具类型	常用工具
项目管理	Microsoft Project、JIRA、Trello
版本控制	Git、Subversion、Mercurial
代码审查	Crucible、SonarQube、CodeClimate
自动化测试	Selenium（功能）、JMeter/LoadRunner（性能）、OWASP ZAP（安全）
CI/CD	Jenkins、Travis CI、CircleCI、GoCD

7.4 开源管理

使用开源技术时应关注：选择、效果评估、使用规范、知识产权。可建立项目级或组织级的开源软件应用规范和资源库，预留备选方案。

八、6.7 软件过程能力成熟度（CSMM）★★

由T/CESA 1159《软件过程能力成熟度模型》界定。

4个能力域

能力域	包含子域
治理	战略与治理、目标管理
开发与交付	需求、设计、开发、测试、部署、服务、开源应用
管理与支持	项目策划、监控、结项、风险管理、质量保证、配置管理、供应商管理
组织管理	过程管理、人员能力管理、组织资源管理、过程能力管理

5个成熟度等级

等级	特征
1级：初始级	过程结果不确定，依赖个人主动性，无完整管理规范
2级：项目规范级	依据选择和定义的管理规范执行，组织提供支持保障
3级：组织改进级	建立并持续改进组织标准过程和过程资产，项目贡献过程资产
4级：量化提升级	使用统计分析技术，建立量化的质量与过程绩效目标
5级：创新引领级	通过技术和管理的创新提升组织竞争力，引领行业发展

💡 考试提示：CSMM等级特征注意区分——初始级"人治"、项目规范级"制度和规范"、组织改进级"持续改进"、量化提升级"量化分析和统计"、创新引领级"创新引领"。

九、6.8 软件工厂 ★

软件工厂是一种软件开发的组织和管理模式，将软件开发视为工业化生产过程。

9.1 软件工厂构成

构成	说明
专业人员	开发工程师、测试工程师、项目经理、产品主管
基础设施和硬件	终端计算机、服务器、网络设备
工具和技术	项目管理工具、IDE、自动化测试工具、版本控制系统
流程规范和方法论	DevOps、CI/CD等
质量管理	软件测试、代码审查、性能测试

9.2 与传统开发对比

关键差异：软件工厂更注重敏捷交付、流水线作业、安全可控、协同开发。

敏捷交付：Scrum/Kanban、用户故事、迭代开发、自动化测试、CI/CD、可视化管理
流水线作业：环节划分 → 任务定义 → 流转规则 → 并行处理 → 自动化支持 → 监控优化
安全可控：安全开发实践（安全需求/设计/编码/测试）、数据和隐私保护、CI/CD、安全培训
协同开发：站会/评审会/回顾会、知识共享（文档/代码审查/技术分享）、协作工具（微信/钉钉/WPS等）

9.3 建设方法

方面	内容
组织建设	确定组织结构、明确岗位职责、设计流程规范、优化沟通渠道、培养团队文化
资源部署	基础设施、工具平台、人力资源
业务管理	项目/需求/质量/风险管理
体系保障	制度体系、评估体系、持续改进机制

十、高频考点速记

考点频率统计

考点	频率	常见题型
软件需求分析（SA-DFD/OOA-层次）	⭐⭐⭐⭐⭐	选择/案例（DFD图）
软件设计（SD-耦合内聚/SC/UML/OOD原则）	⭐⭐⭐⭐	选择/案例辨析
软件测试（白盒/黑盒/测试类型/覆盖标准）	⭐⭐⭐⭐	选择/案例
常见开发过程模型辨析	⭐⭐⭐	选择（场景判断）
SRS内容与需求规格	⭐⭐⭐	选择
需求变更控制与CCB	⭐⭐⭐	选择
软件配置管理SCM	⭐⭐⭐	选择
软件质量保证SQA	⭐⭐⭐	选择
UML图与视图	⭐⭐	选择
需求跟踪（正向/逆向/双向）	⭐⭐	选择
设计模式分类（创建/结构/行为）	⭐⭐	选择
CSMM成熟度等级	⭐⭐	选择
持续交付/部署（CI/CD）	⭐⭐	选择
软件工厂概念与特点	⭐	选择

易混淆点辨析

🔴 瀑布 vs 迭代 vs 增量 vs 螺旋 vs 敏捷

瀑布=线性顺序、迭代=重复迭代全功能、增量=逐步追加功能、螺旋=迭代+风险分析、敏捷=灵活快速变化

🔴 结构化分析(SA) vs 面向对象分析(OOA)

SA=数据流驱动(DFD+数据字典)，面向过程/功能分解 OOA=对象驱动(类/对象)，强调抽象/封装/继承

🔴 白盒测试 vs 黑盒测试

白盒=关注内部结构逻辑（逻辑覆盖），黑盒=关注功能（等价类/边界值）

🔴 耦合 vs 内聚

耦合=模块间联系程度（要低），内聚=模块内聚程度（要高）口诀：高内聚、低耦合

🔴 质量控制 vs 质量保证

控制是具体措施（如何满足），保证是提供信任证据（使对方信任）

🔴 验证 vs 确认

验证：是否正确地构造了产品（验证过程符合规范）确认：是否构造了正确的产品（确认满足用户需求）

🔴 正向跟踪 vs 逆向跟踪

正向：需求 → 后续工作成果逆向：工作成果 → 需求出处

记忆口诀汇总

口诀	对应内容	详解
"高内聚低耦合"	模块设计原则	模块内部高度相关，模块间尽量独立
"业用系"	需求三层次	业务需求、用户需求、系统需求
"功非约"	系统需求三类	功能需求、非功能需求、约束
"常规期望意外"	QFD需求分类	常规需求、期望需求、意外需求
"数功行"	SA三层模型	数据模型(E-R)、功能模型(DFD)、行为模型(STD)
"主对结属服"	OOA五层次	主题层、对象类层、结构层、属性层、服务层
"抽封继分聚，关消粒行"	OOA九原则	抽象、封装、继承、分类、聚合、关联、消息通信、粒度控制、行为分析
"单开里依接组迪"	OOD七原则	单一职责、开闭、里氏替换、依赖倒置、接口隔离、组合重用、迪米特
"实控边"	OOD三类	实体类、控制类、边界类
"类对构件组，包部制"	UML结构图(7种)	类、对象、构件、组合结构、包、部署、制品
"用顺通定状态活交"	UML行为图(7种)	用例、顺序、通信、定时、状态、活动、交互概览
"创建结构行为"	设计模式三类	创建型、结构型、行为型
"单集确配回" 或 "单集成确配系统回归"	测试类型	单元、集成、确认、系统(配置项)、回归
"最初项目，组改量创"	CSMM五级	初始级、项目规范级、组织改进级、量化提升级、创新引领级

💡 复习建议：本章是全书中概念密度最高的章节之一。6.2（软件需求）和6.3（软件设计）是上午考试的重灾区，题型以概念辨析为主。建议重点掌握SA与OOA的区别、DFD建模方法、耦合/内聚的类型辨析、UML图分类及用途、测试类型和测试方法辨析。CSMM和软件工厂了解特征并能区分各等级即可。