📚 第5章 软件工程（上篇）

📘 知识点精华总结（上篇：5.1-5.3节）

⭐ 软考超级重点章节 |系统集成项目管理工程师

📑 本篇目录

• 5.1 软件工程定义
• 5.2 软件需求
• 5.3 软件设计

5.1 软件工程定义

🎯 软件工程的定义与目标⭐⭐⭐

软件工程定义：应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程。

目的：提高软件生产率、提高软件质量、降低软件成本。

IEEE定义：将系统的、规范的、可度量的工程化方法应用于软件开发、运行和维护的全过程及上述方法的研究。

Fritz Bauer定义：建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法。

💡 记忆口诀："三高一低"——高生产率、高质量、高效率；低成本

🔧 软件工程的三个组成部分⭐⭐

💡 记忆口诀："工具支持过程，方法指导实践"

📊 软件危机的表现⭐⭐

1968年首次提出软件危机（Software Crisis）概念，具体表现为：

• 软件开发进度难以预测
• 软件开发成本难以控制
• 软件功能难以满足用户期望
• 软件质量无法保证
• 软件难以维护
• 软件缺少适当的文档资料

📝 历年真题示例：软件危机的表现不包括以下哪项？A. 进度难以预测   B. 成本难以控制   C. 文档资料完善   D. 质量无法保证答案：C（文档资料完善不是危机表现）

5.2 软件需求

🔑 核心概念：软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。根据IEEE标准，软件需求是指用户解决问题或达到目标所需要的条件或能力。

5.2.1 需求的层次

📚 需求的三层结构 ⭐⭐⭐⭐⭐⭐⭐⭐⭐

系统需求的细分：

• 功能需求（行为需求）：
  规定开发人员必须在系统中实现的软件功能
• 非功能需求：
  描述系统展现给用户的行为和执行的操作，包括产品质量属性（易用性、可维护性、效率等）
• 设计约束：
  对开发人员在软件产品设计和构造上的限制（如必须采用安全可靠的自主知识产权数据库系统）

💡 记忆口诀："业务定方向，用户说任务，系统分三类（功能+非功能+约束）"

📝 历年真题示例：以下哪个不属于软件需求的常用层次？A. 业务需求   B. 用户需求   C. 数据需求   D. 系统需求答案：C（数据需求不属于标准的三层结构）

5.2.2 质量功能部署（QFD）

🎯 QFD的三类需求⭐⭐

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

💡 记忆口诀："常规越多越满意，期望不做就不满，意外做了更高兴"

5.2.3 需求获取

🔍 需求获取的五种方法 ⭐⭐⭐⭐⭐⭐⭐⭐⭐

💡 记忆口诀："访谈问卷采样，情节串联JRP"

⚠️ 易错点提醒：需求获取是开发方、用户之间为定义新系统而进行的交流。如果双方所理解的领域内在系统分析、设计过程出现问题，通常在开发过程的后期才会被发现，将会使整个系统交付延迟，或行上线后系统无法或难以使用，最终导致项目失败。

5.2.4 需求分析

🔬 结构化分析方法（SA）⭐⭐⭐⭐⭐⭐⭐⭐

结构化分析（Structured Analysis, SA）方法给出一组帮助系统分析人员产生功能规约的原理与技术，其建立模型的核心是数据字典。

三个层次的模型：

📊 数据流图（DFD）的基本元素⭐⭐⭐⭐

DFD由以下4种基本元素组成：

💡 记忆口诀："外处理存储流"——外部项→处理→数据存储→数据流

📖 数据字典的内容⭐⭐⭐

数据字典（Data Dictionary）是对数据的数据项、数据结构、数据流、数据存储、处理逻辑等进行定义和描述，其目的是对数据流图中的各个元素做出详细的说明。

数据字典主要包括以下部分：

• 数据项：
  不可再分的数据单元，描述包括名称、含义、别名、类型、长度、取值
  范围等
• 数据结构：
  反映数据之间的组合关系
• 数据流：
  数据结构在系统内传输的路径
• 数据存储：
  数据结构停留或保存的地方
• 处理过程：
  只需要描述说明性信息，包括输入、输出和处理简要说明

🔄 面向对象分析方法（OOA）⭐⭐⭐

面向对象的分析（Object-Oriented Analysis, OOA）方法能正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责。

OOA模型的组成：

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

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

两种对象类结构：

• 分类结构：
  一般与特殊的关系（继承关系）
• 组装结构：
  整体与部分的关系（聚合关系）

💡 记忆口诀："五层五活动，九大原则记心间"

5.2.5 需求规格说明书（SRS）

📋 SRS的主要内容 ⭐⭐⭐⭐⭐⭐⭐⭐

软件需求规格说明书（Software Requirement Specification, SRS）是在需求分析阶段主要要完成的文档，是软件需求分析的最终结果。

根据国家标准《计算机软件文档编制规范》（GB/T 8567），SRS应该包括：

1. 范围：
   适用的系统和软件的完整标识、用途、一般特性等
2. 引用文件：
   SRS中引用的所有文档
3. 需求：
   SRS的主体部分，详细描述软件需求
• 所需的状态和方式
• 需求概述
• 需求规格
• 软件配置项能力需求
• 外部接口需求、内部接口需求
• 适应性需求、保密性和私密性需求
• 环境需求、计算机资源需求
• 软件质量因素、设计和实现约束
• 数据、操作、故障处理等
4. 合格性规定：
   定义合格性的方法（演示、测试、分析、审查等）
5. 需求可追踪性：
   双向可追踪性
6. 尚未解决的问题
7. 注解：
   背景信息、词汇表、原理等
8. 附录：
   便于维护的独立编排信息

📝 历年真题示例：以下哪个不属于软件需求规格说明书的内容？A. 业务功能   B. 交互界面   C. 应用系统性能   D. 算法的详细过程答案：D（算法的详细过程属于详细设计阶段的内容）

✅ 需求验证⭐⭐⭐

需求验证（需求确认）的活动摘要确定的内容包括：

• SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征
• SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的
• 需求是完整的和高质量的
• 需求的表示在所有地方都是一致的
• 需求为继续进行系统设计、实现和测试提供了足够的基础

验证方法：需求评审（技术评审）+ 需求测试

5.2.6 需求变更

🔄 变更控制过程 ⭐⭐⭐⭐⭐⭐⭐⭐

变更控制的步骤：

常见的需求变更策略：

• 所有需求变更必须遵循变更控制过程
• 对于未获得批准的变更，不应该做设计和实现工作
• 应该由项目变更控制委员会（CCB）决定实现哪些变更
• 项目风险承担者应该能够了解变更的内容
• 绝不能从项目配置库中删除或修改变更请求的原始文档
• 每一个集成的需求变更必须能跟踪到一个经核准的变更请求

💡 记忆口诀："分析描述→成本计算→变更实现"三步走

🏛️ 变更控制委员会（CCB）⭐⭐⭐

变更控制委员会（Change Control Board, CCB）是项目所有者权益代表，负责裁定接受哪些变更。

CCB的特点：

• CCB是决策机构，不是作业机构
• 通常CCB的工作是通过评审手段来决定项目是否能变更
• CCB不提出变更方案

CCB可能包括的代表：产品或计划管理部门、项目管理部门、开发部门、测试或质量保证部门、市场部或客户代表、用户文档编制部门、技术支持部门、桌面或用户服务支持部门、配置管理部门

⚠️ 易错点提醒：CCB是决策机构而非执行机构！它只负责评审和决策，不负责具体的变更实施工作。

5.2.7 需求跟踪

🔗 需求跟踪矩阵（RTM）⭐⭐⭐⭐⭐⭐

需求跟踪包括编制每个需求与系统元素之间的联系文档，这些元素包括其他需求、体系结构、其他设计部件、源代码模块、测试、帮助文件和文档等。

需求跟踪的两种方式：

正向跟踪和逆向跟踪合称为"双向跟踪"。不论采用何种跟踪方式，都要建立和维护需求跟踪矩阵（表格）。

💡 记忆口诀："正向查需求是否落地，逆向查工作是否有据"

5.3 软件设计

🔑 核心概念：软件设计的目的是绘制软件的蓝图，权衡和比较各种技术和实施方法的利弊，合理分配各种资源，构建新的详细设计方案和相关模型，指导软件实施工作的顺利开展。需求阶段解决"做什么"的问题，软件设计阶段解决"怎么做"的问题。

5.3.1 结构化设计

🏗️ 结构化设计（SD）概述⭐⭐⭐

结构化设计（Structured Design, SD）是一种面向数据流的方法，其目的在于确定软件结构。SD是一个自顶向下、逐层分解、逐步求精和模块化的过程。

两个阶段：

• 概要设计（总体结构设计）：
  确定软件系统的结构，进行模块划分，确定每个模块的功能、接口和调
  用关系，形成软件的模块结构图（系统结构图）
• 详细设计：
  为每个模块设计实现的细节，包括输入/输出设计、处理流程设计、数据
  存储设计、用户界面设计、安全性和可靠性设计等

🧩 模块的基本特性⭐⭐⭐

模块是实现功能的基本单位，具有3个基本属性：

• 功能：
  该模块"做什么"
• 逻辑：
  描述模块内部"怎么做"
• 状态：
  该模块使用时的环境和条件

模块的外部特性 vs 内部特性：

• 外部特性：
  模块名、参数表、对程序乃至整个系统的影响
• 内部特性：
  完成其功能的程序代码和仅供该模块内部使用的数据

对于模块的外部环境来说，只需要了解这个模块的外部特性就足够了，不必了解它的内部特性。

🔗 模块的耦合类型（7种）⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐

耦合表示模块之间联系的程度。耦合度从低到高排序（越好→越差）：

💡 记忆口诀（从好到差）："非数标控外公内"——非直接→数据→标记→控制→外部→公共→内容

📝 历年真题示例：以下哪种耦合类型是最差的？A. 数据耦合   B. 控制耦合   C. 公共耦合   D. 内容耦合答案：D（内容耦合是最差的耦合类型）

⚙️ 模块的内聚类型（7种）⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐

内聚表示模块内部各成分之间联系的紧密程度。内聚度从高到低排序（越好→越差）：

设计原则："高内聚、低耦合"——系统中各模块的内聚越高，则模块间的耦合就越低。

💡 记忆口诀（从好到差）："功顺通过时逻偶"——功能→顺序→通信→过程→时间→逻辑→偶然

⚠️ 易错点提醒：内聚是从高到低排序（功能内聚最好），耦合是从低到高排序（非直接耦合最好）。不要混淆两者的排序方向！

📐 详细设计的工具⭐⭐

详细设计的表示工具有图形工具、表格工具和语言工具三类：

1) 图形工具：

• 业务流程图：
  描述管理系统内各单位、人员之间的业务关系、作业顺序和管理信息流向
• 程序流程图（程序框图）：
  使用最广泛的描述程序逻辑结构的工具
• NS流程图（盒图/方框图）：
  强制使用结构化构造的图示工具，功能域明确、不可能任意转移控制
• PAD图（问题分析图）：
  改进的图形描述方式，能够反映自顶向下的历史和过程

2) 表格工具：用一张表描述过程的细节，列出各种可能的操作和相应的条件

3) 语言工具：用高级语言描述过程的细节，如伪码或PDL（Program Design Language）

5.3.2 面向对象设计

🎨 面向对象设计（OOD）原则 ⭐⭐⭐⭐⭐⭐⭐⭐

面向对象设计（Object-Oriented Design, OOD）是OOA方法的延续，其基本思想包括抽象、封装和可扩展性（主要通过继承和多态实现）。

常用的OOD七大设计原则⭐⭐⭐⭐⭐：

💡 记忆口诀："单开里依接组迪"——单一职责、开闭、里氏替换、依赖倒置、接口隔离、组合重用、迪米特

📦 OOD中的三种类⭐⭐⭐

💡 记忆口诀："实体存数据，控制管逻辑，边界做交互"

5.3.3 统一建模语言UML

🎭 UML的结构 ⭐⭐⭐⭐⭐⭐⭐⭐

统一建模语言（Unified Modeling Language, UML）是一种定义良好、易于表达、功能强大且普遍适用的建模语言。

UML的结构包括3个部分：

🎨 UML中的事物（建模元素）⭐⭐⭐

🔗 UML中的四种关系 ⭐⭐⭐⭐⭐⭐⭐⭐

💡 记忆口诀："赖关联泛实"——依赖、关联、泛化、实现

📊 UML 2.0的14种图 ⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐

💡 记忆口诀（14种图）："类对构组用，顺通定时状活，部制品包交"类图、对象图、构件图、组合结构图、用例图、顺序图、通信图、定时图、状态图、活动图、部署图、制品图、包图、交互概览图

📝 历年真题示例：以下哪种图属于UML 2.0的交互图？A. 类图   B. 顺序图   C. 状态图   D. 部署图答案：B（交互图包括：顺序图、通信图、定时图、交互概览图）

🖼️ UML的4+1视图 ⭐⭐⭐⭐⭐⭐⭐⭐

💡 记忆口诀："逻辑进程实现部署，外加用例场景全" —— 4+1视图

5.3.4 设计模式

🏛️ 设计模式三大类23种模式 ⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐

设计模式是前人经验的总结，使人们可以方便地复用成功的软件设计。根据目的和用途不同，设计模式分为3大类：

📦 一、创建型模式（5种）——主要用于创建对象

🔗 二、结构型模式（7种）——主要用于处理类或对象的组合

⚡ 三、行为型模式（11种）——主要用于描述类或对象的交互以及职责分配

💡 记忆口诀（23种模式）：创建型（5）："工厂抽象单建原"——工厂方法、抽象工厂、单例、建造者、原型结构型（7）："适配桥组合装饰外观享元代理"——适配器、桥接、组合、装饰器、外观、享元、代理行为型（11）："解释模板责任命令迭代中介备忘观察状态策略访客"——11种模式

📝 历年真题示例：以下哪种设计模式属于创建型模式？A. 适配器模式   B. 单例模式   C. 观察者模式   D. 策略模式答案：B（单例模式属于创建型模式，A属结构型，C、D属行为型）

💡 适用于系统集成项目管理工程师考试复习 | 基于教材原文整理

⚠️ 本文档仅供学习参考，请结合官方教材使用