软件工程——期末复习知识点汇总

本帖的资料来源于某国内顶流高校的期末考试资料，仅包含核心的简答题，大家结合个人情况，按需复习~

---

总的来说，大层面重点包括如下几个方面：

• 软件过程
• 需求工程
• 设计工程
• 软件测试
• 软件项目管理
• 软件过程管理

1.掌握软件生命周期的几个活动（目标、任务、输出）

(1) 需求分析（需求工程）

目的：根据描述明确问题域特性 E ，构建定义良好的系统行为 S ，使得 E 通过 S ，达

到预期的需求 R

需求工程的主要工作：

(a) 研究问题背景，描述问题域特性 E

(b) 需求开发 , 确定 R

(c) 构建解系统，描述解系统行为 S ，使得 E , S ——   R

理解现实为第一目的，保证 S 的质量为第二目的

结果 : SRS (Software Requirements Specification) 用户需求规格说明

(2) 设计：

目的：以软件实体为基础建立软件结构即整个将要开发的系统的模型或设计表示

任务： (a) 体系结构设计

(b) 细节设计

(c) 用户界面设计 =(HCI) ？

结果：模型：体系结构模型，系统模型

规格说明书：体系结构说明，系统构件说明，界面设计文档

设计决策会极大的影响系统质量，所以要有多种选择和折中

(3) 实现

目的：用编程语言实现系统中单独的组件

任务： 程序设计、编程、调试

结果 ：可执行的程序

(4) 测试

目的：验证和确认软件质量

任务：测试设计、单元测试、集成测试、系统测试 | 、确认测试、回归测试

结果：发现的缺陷和错误

测试不一定要在实现结束后进行，可能并行进行，如果测试用例从需求确认中直接

得出，可能影响需求分析

(5) 安装与维护

目的：在系统向用户发布后保持系统的运行，包括完善型 (Perfective) 、调整型

(Adaptive) 、修正型 (Corrective) 、防止型维护 (Preventive)

任务：安装，培训，维护

输出：正常运转的系统

2.针对于各种软件过程模型的描述（特征描述 优点 缺点）

(6) 螺旋模型

描述：每个框架活动代表螺旋上的一个片段，随着演化的开始，从圆心开始顺时针方向，执行螺旋上的一圈表示的活动。每次演化都要考虑风险。标记里程碑——沿 着螺旋路径达到的工作产品和条件的结合体

特征：在每个阶段的演化中用瀑布模型 + 风险驱动 + 原型开发

内圈表示早期的系统分析和原型，外圈表示经典瀑布模型的其他方面

优点：

• 采用循环的方式逐步加深系统定义和实现的深度，降低风险
• 确保共利益者都支持可行的和令人满意的系统解决方案
• 在项目的所有的阶段考虑风险，适当利用该方法，能够在风险变为问题前化解风险

缺点：

• 依赖大量的风险评估专家来保证成功，如果所有的风险不能解决，项目就会立即停止
• 只适用于大规模的项目

3.理解软件和现实世界的互动机制

软件与现实世界的互动：

(1) 当现实的状况与人们期望的状况产生差距时，就产生了问题。

(2) 要解决问题，就需要改变现实当中某些实体的状态或改变实体状态变化的演进顺序， 使其达到期望的状态或演进顺序。

(3) 这些实体和状态构成了问题解决的基本范围，称为该问题的问题域（ Problem Domain ）

(4) 软件系统通过影响问题域，能够帮助人们解决问题，称为解系统

共享现象：

(1) 软件系统能够与问题域进行交互和相互影响的原因在于，软件系统中的某些部分对问题域中的某些部分的具有模拟特性。

(2) 换句话说，软件系统当中含有问题域某些部分的模型（或模拟），常见的模型包括数据模型、对象模型、处理模型等。

(3) 问题域中的某些信息能够和模型中的信息建立 映射 关系

(4) 这些通过映射建立的共同知识，就是问题域和解系统之间的共享现象

需求 是用户对问题域当中的实体状态或事件的期望描述

直接需求是可以通过更改共享现象被满足的需求 ;

需求关注的是现实世界中的部分，软件关注的是解系统，而规格说明关注的是共享现象

规格说明是解系统为满足用户需求而提供的解决方案，规定了解系统的行为特征

主要包括两个部分：

（ 1 ）对共享现象（模型）的描述；

（ 2 ）系统对共享现象所施加的操作的描述。

 

4.需求的分类

(1) 功能需求（ Functional Requirement ）： 与系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。 功能需求主要表现为系统和环境之间的行为交互。

(2) 性能需求（ Performance Requirement ）： 系统整体或系统组成部分应该拥有的性能特征，例如 CPU 使用率、内存使用率等。

(3) 质量属性（ Quality Attribute ）： 系统完成工作的质量，即系统需要在一个“好的程度”上实现功能需求，例如可靠性程 度、可维护性程度等。

(4) 对外接口（ External Interface ）： 系统和环境中其他系统之间需要建立的接口，包括硬件、软件接口、数据库接口等

(5) 约束：进行系统构造时需要遵守的约束，例如编程语言、硬件设施等

5.描述需求工程的活动

(1) 需求起始：解决业务需求

活动：

建立项目范围和前景 ( 涉众分析、确定涉众、识别多种观点、协商合作、首次提问)

(2) 需求导出：

活动：

• 协同需求收集、质量功能部署(QFD)、开发用户场景和用例，导出工作产品
• QFD:将客户要求转化成软件技术需求的技术。强调“什么是对客户有价值的”；
• 确认了三种需求：正常需求、期望需求、令人兴奋的需求
• 产品：需要及可变性的陈述，对系统和产品的范围描述，客户及其他涉众人员名单系统技术环境的描述，一系列需求以及各需求实现的限制，不同操作环境下的用例，能更好的确定需求的各种原型

(3) 需求精化：开发一个精确的技术模型，用以说明软件的功能、特征和约束。是一个分析建模的动作，最终结果是分析模型，定义问题的信息域、功能域、行为域，精化与导出交互进行~

• 活动：分析模型的元素(基于场景的、基于类的元素、行为元素、面向信息流的元素)
• 建立一个能够识别出数据和行为特性的模型
• 利用分析模式建立需求分析模型

(4) 需求协商：在一个开发者和用户都能接受的现实的能发布的产品上达成一致

活动：

• 识别系统或子系统关键的共利益者
• 确定共利益者“赢”的条件
• 就共利益者“赢”的条件进行协商使其与所有涉及人的一系列双赢条件一致

(5) 需求规格说明：需求工程师完成的最终工作产品，将作为软件工程师活动的基础， 描述了一个基于计算机系统的功能、性能以及影响系统开发的约束。可以用自然语言描述和图形化的模型来编写，也可以只是使用场景

(6) 需求验证：对需求工程的工作产品进行质量评估。检查规格以保证：所有的系统需求无歧义的说明，不一致性疏漏和错误已被检测出并被修正，工作产品符合为过程、项目和产品建立的标准。

(7) 需求管理：用于帮助项目组在项目进展中标识、控制和跟踪需求以及变更需求的一

组活动：

• 在需求发展后发布基线
• 保持跟踪表
• 变更控制

6.理解设计理论的 7 个特征，并掌握它们在软件设计上的影响

(1) 设计起始于需求的目的：设计前需要需求工程

(2) 设计通常引起转化：软件改变世界， 需求、共享现象、领域特征 组成软件设计的基础，也就是分析模型

(3) 设计需要创造性：新思想的产生是设计理论的基础

无论何时 , 只要有一个从现实到未来可能的充满想象力的飞跃 , 设计就会发生 ; 新思想产生的精确方式是难以系统化表示的 影响 : 设计理论的一般风格：抽象，精化

软件设计的具体风格：模块化和信息隐藏，新思想产生的影响：软件功能独立

创造性：抽象， 精化 ，模块化，信息隐藏。抽象包括：行为抽象（只显现功能，隐藏具体实

现） 数据抽象（对数据对象进行抽象）；精化（与抽象相反的过程，将抽象时没有考虑的细节考虑进去；对抽象级上的功能加以具体实现，考虑层次结构设计）模块化（把软件划分成相互独立的部分，通过部分的集成来满足需求，要符合高内聚低耦合的特点）。信息隐藏：抽象的重要手段，模块化，抽象是信息隐藏的直接 结果。每个模块对其他模块隐藏它的具体设计决策。

(4) 设计需要满足约束：原始的需求确定了部分约束，大部分约束在设计的过程中逐渐被发现

影响：软件质量管理，尤其是非功能的需求的管理

(5) 设计是一个问题求解和决策的过程：设计问题的解决空间很多，设计的特征在于在一系列的选择中做决定。

软件需要看重基础原则的决定，（如体系结构的设计决定；）软件需要通过不同方面来划分做决定的工作（，如分为界面设计，安全设计，分配设计，实时设计等）

(6) 设计能产生用来实现最终产品的进度安排：产生软件设计模型

(7) 设计具有多样性和演化性：任何细节设计都有多种实现，在不同的实现方式之间的决策，使得设计具有多样性，由于不断的决策，设计也要不断演化使设计与当前情况相符合。随着演化的进行，需求和约束也会逐渐明晰。

软件设计中的多样性，决定软件在设计时可以使用已有的问题解决模式 ，如：体系结构模型，设计模型，代码模型等。同时，软件设计需要用重构 等方法进行演化，软件的设计需要复用框架构件等比较成功的解决方案。

7.理解常见的体系结构风格

(1) 以数据为中心的体系结构

(2) 数据流体系结构

(3) 调用返回体系结构

(4) 层次体系结构

层次结构：定义了一系列不同层次，每个层次各自完成操作。这些操作不断接近机器的指令集。最外层，构件完成用户界面的操作，最内层，构件完成 与操作系统的连接；中间层提供各种实用程序服务和应用软件的功能。

(5) 面向对象体系结构

构建封装数据和必要的操作 , 构件间通过信息传递进行通信与合作。

8.类设计原则

(0) 单一职责原则 (SRP): 一个类的改变只能出于一种原因

(1) 开关原则： 模块应该对外延具有开放性，对修改具有封闭性。 设计者应该采用一种无须对构件自身内部做修改就可以进行扩展的方式来说明构件。在扩展的功能与设计类本身之间分离出一个缓冲区。

(2) Liskov 替换原则： 子类可以替换它们的基类。 将子类传递给构件来代替基类时使用基类的构件仍能工作。任何子类必须遵守基类与使用该基类的构件之间的隐含约定。

(3) 依赖倒置原则： 依赖于抽象而非具体实现。 抽象可以比较容易的扩展，不会导致大的混乱。构件依赖的具体构件越多，扩展越困难。

(4) 接口分离原则： 多个用户专用接口比一个通用接口好。 否则会产生多目标类和不必要的依赖。

9.能够列出至少 5 个界面设计的原则，并加以解释

(1) 置用户于控制之下 ：

以不强迫用户进入不必要的或不希望的动作的方式来定义交互模式；

提供灵活的交互；

允许用户中断或撤销交互。

把用户与内部技术细节隔离开来

(2) 减轻用户的记忆负担

减轻对短期记忆的要求

建立有意义的缺省

定义直观的快捷方式

界面的视觉布局应该基于真实世界的象征

以不断进展的方式揭示信息

(3) 保持界面一致

允许用户将当前任务放入有意义的环境中

在应用系统家族内保持一致性

如果过去的交互模型已经建立起了用户期望，除非有不得已的理由，否则不要改变它。

(4) 使用用户语言及友好的错误提示，好的错误提示需要告诉用户发生了什么，需要怎么改进

]

(5)  提供帮助和文档，并且应该放在用户易于访问的位置

10.能够描述测试的 5 个层次 主要工作

(1) 单元测试： 检测单个模块的行为 ，侧重以源代码形式实现的每个单元，它充分利用测试技术，检查构件中每个控制结构的特定路径以确保完全覆盖。注意边界测试。

(2) 集成测试： 测试模块之间相互协作时的工作情况。 普遍使用关注输入和输出的测试用例设计技术。常用增量集成（自顶向下、自底向上集成），冒烟测试

(3) 验收测试： 将软件的行为与用户的最终需求进行比较 ，常用于安装测试， α 测试，β 测试

(4) 系统测试： 软件行为与需求规格说明书进行比较， 将软件与系统的其他成分作为一个整体来测试，包括安全测试，压力测试，性能测试，恢复测试

(5) 回归测试： 查看新的版本中软件的行为 。回归测试可能包括以上各个层次的重新测试来保证改变没有引进新的错误。

11.能够描述白盒测试和黑盒测试，并进行优缺点比较

12.能解释并区别白盒测试三种不同的方法：语句覆盖、分支覆盖和路径覆盖

13.掌握 LOC 和 FP 两种估算单位，能够说明各自的优缺点

14.理解几种图示工具的使用

所有的项目任务在左边的栏中列出，水平条表示各个任务的工期，同一时段中存在多个水平条时，代表任务之间的并发性，菱形表示里程碑。

人员安排：

15.能够解释风险管理过程

(1) 风险识别：指出对项目计划的威胁。识别已知的和可预测的风险。一种方法是建立风险条目检查表。识别产品规模、商业影响、客户特性、过程定义、开发环境、开发技术、人员才干及经验等类型中的风险。

(2) 风险分析：估计每个风险的可能性或概率；风险相关问题产生的后果。

活动：建立一个尺度，以反映风险发生的可能性。 描述风险产生的后果,估计风险对项目及产品的影响。 标明风险预测的整体精确度，以免产生误解。

(3) 风险计划：考察每一个风险并且为风险的管理开发一个策略。包括：

风险回避，风险最小化，应急计划

(4) 风险跟踪和控制：

评估每一个确定的风险，跟踪看它的可能性变大还是变小。评估风险的影响是否发生变 化

16.为什么进行软件项目度量

可以提供能够引导长期的软件过程改进的一组过程指标，使得软件项目管理者能够：

(1) 评估正在进行中的项目状态

(2) 跟踪潜在的风险

(3) 在问题造成不良影响之前发现他们

(4) 调整工作流程或任务

(5) 评估项目团队控制软件工作产品质量的能力

17.描述 SQA Group 的主要活动

18.能够简要描述 SCM process 主要活动各个活动的目的，主要工作

SCM 的目标：

1) 标识变更

2) 控制变更

3) 保证正确地实现变更

4) 向那些利害相关的人员报告变更

软件配置管理过程中的一系列任务中的四个主要目标：

(1) 统一标识软件配置项

(2) 管理一个或多个软件配置项的变更

(3) 便于构造应用的不同版本

(4) 在配置随时间而演化时，确保能够保持软件质量