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

---

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

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

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) 数据流体系结构

8.类设计原则

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

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