2020~2021《软件工程》复习记录

《软件工程》复习提纲_loushanglaoliu

​

一、知识点

1、计算机软件（了解）

​ 软件的基本概念：计算机软件软件指计算机系统中的程序及其文档；其中程序是指计算任务的处理对象和处理规则的描述（形式上是source，binary）；文档是为了便于了解程序所需的阐明性资料。

​ 特点：

1. 软件是一种逻辑实体，而不是有形的系统元件，其开发成本和进度难易准确估算。
2. 软件是被开发的或被设计的，没有明显的制造过程，一旦开发成功，只需复制即可，但其维护工作量大。
3. 软件的使用没有硬件那样的机械磨损和老化的问题

​ 分类：

1. 系统软件：居于计算及系统中最靠近硬件的一层。例子：编译程序，操作系统。
2. 支撑软件：支撑软件开发、维护与运行的软件。例子：数据库管理系统、网络软件、软件工具、软件开发环境。
3. 应用软件：特定应用领域专用软件。例子：人口普查软件、嵌入式应用软件。

2、软件工程（掌握）

软件工程的基本概念，软件生存周期

软件工程的定义（1968年NATO会议上首次提出）：

1. Fritz Bauer:

   软件工程是建立和使用一套合理的工程原则，以便获得经济的软件，这种软件是可靠的，可以在实际及其上高效运行。

2. IEEE（考试回答这个定义）软件工程是：

   1. 将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件。
   2. 在1中所描述的方法的研究

软件生存周期：

1. 计算机系统工程
2. 需求分析
3. 设计
4. 编码
5. 测试
6. 运行和维护

3、软件过程模型（理解）

软件过程的三层含义：

1. 个体含义：即指软件产品或系统在生成周期中某一类活动的集合，如软件开发过程，软件管理过程
2. 整体含义：即指软件产品或系统在所有上述含义下的软件过程的总体。
3. 工程含义：即指解决软件过程的工程，它应用软件工程的原则、方法来构造软件过程模型，并结合软件产品的具体要求进一步实例化，以及在用户环境下的运作，以此进一步提高软件生产率，降低成本。

过程模型的基本概念，主要模型的原理与特点

过程模型的基本概念：软件过程模型是软件开发全部过程、活动和任务的结构框架。也称为：软件开发模型、软件生存周期模型。

1. 基本过程：供给各主要参与方在软件生存周期期间使用。
2. 支持过程：作为有机组成部分来支持其他过程，提高效率和质量。据需要被其他过程应用和执行。
3. 组织过程：基础结构。

主要模型：

1. 瀑布模型
2. 演化模型
3. 增量模型
4. 原型模型
5. 螺旋模型

瀑布模型、原型模型、螺旋模型

瀑布模型：上一阶段的活动完成后向下一阶段的活动过度，最终得到所开发的软件产品。（答题时不能只答概念，不然严尚维老师会觉得是“答非所问”，心情不好时会不给分，因此要加上特征回答）

1970年W.Royce提出瀑布模型

特征：

1. 接受上一阶段的结果作为本阶段的输入
2. 利用这一输入实施本阶段应完成的活动
3. 对本阶段的工作进行评审
4. 将本阶段的结果作为输出，传递给下一阶段

缺点：

1. 缺乏灵活性，难易适应需求不明确或需求经常变化的软件开发。
2. 开发早期存在的问题往往要到交付使用时才发现。维护代价大

原型模型：是预期系统的一个可执行版本，它反映了系统性质（如功能、计算结果等）的一个选定的子集。一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型。可作为单独的过程模型使用，也可以作为一种方法或实现技术应用于其他过程模型中。

原型的类型：

1. 探索型：目的是要弄清楚目标系统的需求，确定所希望的特性，并探讨多种方案的可行性。
2. 实验型：目的是验证方案或算法的合理性，它是在大规模开发和实现前，用于考核方案是否合适，规格说明是否可靠。
3. 演化型：目的是将原型作为目标系统的一部分，通过对原型的多次改进，足部将原型演化成最终的目标系统。

原型的使用策略：

1. 废弃策略：主要用于探索型和实验型原型的开发。这种原型通常要被丢弃，然后根据探索或实验的结果用良好的结构和设计思想宠幸设计目标系统。
2. 追加策略：主要用于演化型原型的开发，这种原型通常是实现了目标系统中已明确定义的特性的一个子集。通过对它的不断修改和扩充，逐步追加新的要求，最后使其演化成最终的目标系统。

螺旋模型：B.Boehm于1988年提出。是瀑布模型和演化模型的结合，并增加了风险分析。

螺旋模型沿着螺线旋转，在四个想想上分别表达四个方面的活动:

1. 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件。
2. 风险分析：评价所选的方案，识别风险，消除风险。
3. 工程实施：实施软件开发，验证工作产品。
4. 客户评价：评价开发工作，提出修正建议。

4、计算机系统工程（了解）

计算机系统由哪些元素所构成

计算机系统：通过处理信息来完成某些预定义目标而组织在一起的元素的集合。

计算机系统的构成元素：

1. 软件：指计算机程序、数据结构和先关的工作产品，它们被用于实现所需的逻辑方法、规程和控制
2. 硬件：指提供计算能力的电子设备、支持数据流的互联设备（如网络交换器、电信设备和支持外部功能的机电设备（如传感器、马达等））
3. 人员：指硬件和软件的使用者和操作者。
4. 数据库：指通过软件访问并持久存储的大型有组织信息集合。
5. 文档：指描绘系统的使用和/或操作的描述性信息（如模型、规格说明、使用手册、联机帮助文件、Web站点）
6. 规程：指定义每个系统元素或其外部相关流程的具体使用步骤

5、需求工程

软件需求、需求分析、需求工程的基本概念（理解）

需求工程（课本定义）：需求获取、需求分析与协商、需求建模、需求规约、需求验证和需求管理。

软件需求（理解三个层次：功能、数据、行为）：功能需求、性能需求、用户或人的因素、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密需求、可靠性需求、软件成本消耗与开发进度需求、其他非功能性需求。

需求分析过程（理解）

需求分析原则：

1. 必须能够表示和理解问题的信息域
2. 必须能够定义软件将完成的功能
3. 必须能够表示软件的行为（作为外部事件的结果）
4. 必须划分描述数据、功能和行为模型、从而可以分层次的揭示细节
5. 分析过程应该从要素信息移向细节信息

步骤：信息域，需求协商，需求建模（入门：面向数据流的结构分析方法（SA）；主流：面向数据结构的分析方法；面向对象的分析方法（OOA））

6、软件设计

软件设计包含哪几方面的内容（掌握）

软件设计：是把软件需求变换成软件表示的过程，现在的软件设计分为：数据/类设计，软件体系结构设计，接口设计和部件级设计。

1. 数据/类设计：将分析-类模型变换成类的实现和软件实现所需的数据结构
2. 体系结构设计：体系结构设计定义了软件的整体结构。
3. 接口设计（人机接口，界面原型设计）：描述了软件内部、软件和协作系统之间以及软件同人之间如何通信。
4. 部件级设计（过程设计）：部件级设计将软件体系结构的结构性元素变换为对软件不见的过程性描述。

软件设计的目标：

1. 设计必须实现分析模型中描述的所有显示需求，必须满足用户希望的所有隐式需求。
2. 设计必须是可读、可理解的，使得将来易于编程，易于测试，易于维护。
3. 设计应从实现角度出发，给出与数据、功能、行为相关的软件全貌。

衡量设计的技术标准：

1. 设计出来的结构应是分层结构，从而建立软件成分之间的控制。
2. 设计应当模块化，从逻辑上将软件划分为完成特定功能或子功能的部件。
3. 设计应当既包含数据抽象，也包含过程抽象。
4. 设计应当建立具有独立功能特征的模块。
5. 设计应当建立能够降低模块与外部环境之间复杂连接的接口。
6. 设计应能根据软件需求分析获取的信息，建立可驱动、可重复的方法。

设计过程：

1. 制定规范
2. 体系结构和接口设计
3. 数据/类设计
4. 部件级（过程）设计
5. 编写设计文档
6. 设计评审

模块化、信息隐藏、模块独立性、内聚与耦合（理解）

软件设计原则：

1. 抽象化与逐步求精

   1. 抽象：在软件设计的规模逐渐增大的情况下，控制复杂性的基本策略。
      1. 过程抽象（功能抽象）
      2. 数据抽象
   2. 逐步求精：把问题分解细化

2. 模块化：即把软件按照规定原则，划分为一个个较小的，相互独立的但又相互关联的部件，实际上是系统分解和抽象的过程。

   1. 模块：数据说明、可执行语句等程序对象的集合，它是单独命名的，并且可以通过名字来访问（如：过程，函数，子程序，宏等）。基本要素如下：

      1. 外部要素：名称、功能、接口。
      2. 内部要素：数据结构、程序代码。

   2. 模块独立性：如果模块是相互独立的，当模块变得越小，每个模块花费的工作量越低。当模块的数量增加时，模块间的联系也随着增加，把这些模块联系起来的工作量也随着增加。

      1. 作用：判断模块划分是否合理的衡量标准
      2. 指标：内聚和耦合。后面详解。

      

3. 信息隐藏

   1. 每个模块的实现细节对于其他模块来说应该是隐蔽的。模块中所包含的信息（数据和过程等）不允许其他不需要这些信息的模块使用。
   2. 通过信息隐藏，可定义和实施对模块的过程细节和局部数据结构的存取和限制。

4. 功能独立

   1. 内聚：是一个模块内部各个元素彼此结合的紧密程度的度量

      

      1. 巧合内聚（偶然内聚）：将几个模块中没有明确表现出独立功能的相同程序代码段独立出来建立的模块。
      2. 逻辑内聚：指完成一组逻辑相关任务的模块。
      3. 时间内聚：指一个模块中的所有任务必须在同一段时间内执行。（初始化模块、终止模块）。
      4. 过程内聚：指一个模块完成多个任务，这些任务必须按指定的过程执行。
      5. 通信内聚：指一个模块内所有处理元素都集中在某个数据结构的一块区域中。
      6. 顺序内聚：指一个模块完成多个功能，这些功能又必须顺序执行。
      7. 功能内聚：指一个模块中各个部分都是为完成一项具体功能而协同工作，紧密联系，不可分割的。

   2. 耦合：是模块之间的相互独立性（互相连接的精密程度）的度量

      

      1. 内容耦合：指一个模块直接访问另一个模块的内部数据；或者一个模块不通过正常入口转到另一各模块内部；或者两个模块有一部分程序代码重叠；或者一个模块有多个入口，则两个模块之间发生了内容耦合。
      2. 公共耦合：若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖去等。
      3. 外部耦合：指模块间通过软件之外的环境联结（如I/O将模块耦合到特定的设备、格式、通信协议上）。
      4. 控制耦合：指一个模块传送给另一个模块的参数中包含了控制信息，该控制信息用于控制接收模块中的执行逻辑。
      5. 标记耦合：两个模块之间通过参数传递一个数据结构的一部分（如某一数据结构的字结构）。
      6. 数据耦合：两个模块之间仅通过参数表传递简单数据，则称为数据耦合。
      7. 非直接耦合：指两个模块之间没有直接关系，即它们中的任何一个都不依赖另一个而独立工作，这种耦合称为非直接耦合。

   3. 模块之间的连接越紧密，联系越多，耦合性就越高，而其功能独立性就越弱；一个模块内部各个元素之间的联系越紧密，则它们的内聚性越高；功能独立性比较强的模块应该是高内聚低耦合的模块。

过程设设计的主要注意事项（了解）

过程设计的工作：

1. 为每个部件确定采用的算法，选择合适的工具表达算法的过程，编写部件的详细过程。
2. 描述每个部件内部的数据结构
3. 在部件级设计结束时，把结果写入部件级设计说明书中，整理成正式文档。

过程设计的描述工具：

1. 描述算法过程：流程图、NS图、PAD图等。
2. 描述复杂的判断规则：判定表、判定树等。
3. 伪代码

设计规约主要包含哪些内容（了解）

7、结构化分析（掌握）

结构化方法是一种传统的面向数据流的开发方法

数据流图、数据字典、功能说明

数据流图

1. 数据流图的基本图形元素：数据流、加工、文件（三者用于构件软件系统内部的数据处理模型）；源和宿（表示存在与系统之外的对象）。
2. 数据流的分解：就是画数据流图嘛。

数据字典

1. 数据字典有什么作用？

   数据流图与数据字典是密不可分的，两者结合起来构成软件的逻辑模型。

2. 有哪些内容需要写到数据字典？

   1. 数据流条目

      

   2. 文件条目

      

   3. 数据项条目：名称：数据项

      

   4. 加工条目

      

   5. 源和宿条目

      

   6. 别名条目

      

功能说明

有哪些比较常用的描述方式？

1. 结构化语言
2. 判定表
3. 判定树

8、人机界面设计的主要注意事项（了解)

真的要考吗？

互联网软件与企业应用软件，界面要求有何区别？
前者，吸引用户自发使用，从而获取价值
后者，自下而下强制推行，从而获取价值

9、编程规范（了解）

标识符命名应该注意的问题

1. 选择含义明确的名字，使其能正确提示标识符所代表的实体

​ 例如，表示总量的变量名用 Total ，表示平均值的用 Average 等

2. 名字不要太长，太长会增加打字量，且易出错。必要时可使用缩写
3. 不用相似的名字，相似的名字容易混淆，不易发现错误

​ 如 cm,cn,cmn,cnm,cnn,cmm

4. 不用关键字作标识符
5. 同一个名字不要有多个含义
6. 名字中避免使用易混淆的字符。

​ 如数字0与字母O；数字1与字母I或l；数字2与字母z等

书写功能性注释需要注意哪些问题

1. 注解要正确，错误的注解比没有注解更坏；
2. 为程序段作注解，而不是为每一个语句作注解；
3. 用缩进和空行，使程序与注释容易区分；
4. 注解应提供一些从程序本身难以得到的信息，而不是语句的重复。

编写程序时，对数据说明应该注意哪些问题

1. 数据说明的次序应当规范化

2. 说明语句中变量安排有序化

3. 使用注解说明复杂数据结构

10、软件测试（掌握）

测试目的、测试用例、白盒法与黑盒法的概念

测试用例：一个测试用例由测试输入数据和预期结果组成。测试时通过输入数据，运行被测程序，如果运行的实际输出与预期结果不一致，则表明发现了程序中的错误。

软件测试的目的（Glen Myers）：

1. 测试是一个为了发现错误而执行程序的过程。
2. 一个好的测试用例是指很可能找到迄今为止尚未发现的错误的测试用例。
3. 一个成功的测试是指揭示了迄今为止尚未发现的错误的测试。

测试原则（Davis）：

1. 所有的测试都应可追溯到客户需求。
2. 应该在测试工作真正开始前的较长时间就进行测试计划。
3. Pareto原则：测试中发现的80%的错误可能来自20%的程序代码。
4. 测试应从“小规模”开始，逐步转向“大规模”。
5. 穷举测试是不可能的。
6. 为了达到最有效的测试，应有独立的第三方来承担。

其他的测试原则：

1. 在设计测试用例是，应包括合理的输入条件和不合理的输入条件。
2. 严格执行测试计划，排除测试的随意性。
3. 应该对每一个测试结果做全面检查。
4. 妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便。
5. 检查程序是否做了应做的是仅是成功的一半，另一半是检查程序是否做了不该做的事。
6. 在规划测试时不要设想程序不会查出错误。

白盒测试：也称结构测试，把测试对象看作一个透明的盒子，测试人员根据程序内部的逻辑结构及有关信息设计测试用例，检查程序中所有逻辑路径是否都按预定的要求正确地工作。一般是程序员自己做的测试。

黑盒测试：也称行为测试，把测试对象看作一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只需依据程序的内部规格说明书，检查程序的功能是是否符合它的功能需求。

基本路径测试、逻辑覆盖（几种等级）、循环覆盖（均为白盒测试）

逻辑覆盖：主要考察使用测试数据运行被测程序是对程序逻辑的覆盖程度。通常希望选择最少的测试用例来满足所需的覆盖标准。主要覆盖标准如下：

1. 语句覆盖：每个可执行的语句都至少执行一次（执行路径sabcde）。

    	                                            ![image-20210114163931854](https://gitee.com/LiuXingwu/PicGo/raw/master/img/image-20210114163931854.png)
   

2. 判定覆盖：被测程序的每个判定的所有可能结果都至少执行一次（判定的每个分支至少经过一次）(执行路径sacde或者sabcde)

   ​

3. 条件覆盖：被测试程序的每个判定中的每个条件的所有可能结果都至少出现一次。条件覆盖比判定覆盖强，但有时每个条件的所有可能结果都出现过，但判定表达式的某些可能结果却并未出现。

   ​

4. 判定-条件覆盖：被测程序的每个判定的所有可能结果都至少执行一次，并且，每个判定中的每个条件的所有可能结果都至少出现一次。

5. 条件组合覆盖：被测程序的每个判定中的条件结果的所有可能组合都至少出现一次。

   

6. 路径覆盖：被测程序的每条可能执行到的路径都至少经过一次（如果程序包含环路，则要求每条环路至少经过一次），如果判定条件有n个，则可能的路径有2^n条。

   

基本路径覆盖测试：根据程序或设计图画出控制流图，并计算其区域数，然后确定一组独立的程序执行路径（基本路径），最后为每一条基本路径设计一个测试用例。

1. 程序控制流图（程序图）

   1. 由节点和边组成，分别用圆和箭头表示。
   2. 连续的处理框——对应于程序中的顺序语句
   3. 判定框——对应于程序中的条件控制语句
   4. 箭头——对应程序中的控制转向

   由处理框和判定框映射成流图中的一个节点，箭头映射成流图的一条边。对于多个箭头的交汇点可以映射成流图中的一个节点（空节点）。

   ​

   5. 上述的映射前提是设计图的判定中不包含复合条件。如果包含符合条件则先将其转换成等价的简单条件设计图。

      

   6. 由节点和边组成的笔盒部分称为一个区域，区域的计算：图的外部部分也作为一个区域，下图所示区域数为3

      

   7. 独立路径：指程序中至少引进一个新的处理语句序列或一个新条件的任一路径，在流图中，独立路径至少包含一条该路径之前未曾用到过的边。在基本路径测试时，独立路径的数目就是流图的区域数

循环覆盖

1. 简单循环

   按照下列规则设计测试用例

   1. 零次循环：从循环入口到出口
   2. 一次循环：检查循环初始值
   3. 二次循环：检查多次循环
   4. m次循环：检查多次循环
   5. 最大循环次数
   6. 比最大循环次数多一次循环
   7. 比最大循环次数少一次循环

2. 嵌套循环

   按照下列规则设计测试用例

   1. 先测试最内层循环：所有外层的循环变量置为最小值，最内层按简单循环测试。
   2. 由里到外，则是上一层循环：测试时此层以外的所有外层循环变量取最小值，此层以内的所有嵌套内层循环的循环变量取“典型”值，该层按简单循环测试。
   3. 重复上一条规则，直到所有各层循环测试完毕。
   4. 对全部各层循环同时取最小循环次数，或者同时取最大循环次数。

3. 串接循环

   1. 串接的各个循环互相独立，分别用简单循环的方法进行测试。
   2. 如果第一个循环的循环变量与第二个循环的循环控制有关，即不互相独立。则使用测试嵌套循环的办法来处理。

4. 非结构循环

   先结构化，再测试

等价类（含无效等价类）、边界值（均为黑盒测试）

等价类：等价类是指输入域的某个子集，该子集中的每个输入数据对揭露软件中的错误都是等效的，测试等价类的某个代表值就等价于对这一类其他值的测试。

1. 等价类的划分：把输入划分为有效输入和无效输入。

   1. 有效输入：指符合规格说明要求的合理的输入数据，主要用来检验程序是否实现了规格说明中的功能。
   2. 无效输入：指不符合规格说明要求的不合理或非非阿德输入数据，主要用来检验程序是否做了规格说明以外的事。
   3. 在确定输入数据等价类时，还要分析输出数据的等价类，以便根据输出数据等价类导出输入数据等价类。

2. 确定等价类：根据规格说明，对每一个输入条件确定若干个有效等价类和若干个无效等价类。

   

   确定等价类的规则：

   1. 输入条件规定了取值范围：确定一个有效等价类（符合范围），两个无效等价类（超出上界，超出下界）。
   2. 输入条件规定了值的个数：确定一个有效等价类（符合范围），两个无效等价类（超出上界，超出下界）。
   3. 输入条件规定了输入值的集合（离散值），同时程序对不同输入值做不同处理：每个允许的值都分别确定为一个有效等价类，一个无效等价类（任意一个不允许的值）。例如——成绩分为：优、良、及格、不及格，则可以确定4个有效等价类和一个无效等价类。
   4. 输入条件规定了输入值必须遵循的规则：确定一个有效等价类（符合规则），若干个无效等价类（从各个不同的角度违反此规则）。例如——规定标识符为“以字母开头的······串”，则有效等价类为：“以字母开头的······串”；无效等价类“以数字开头······串”、“以标点符号开头的······串”······
   5. 输入条件规定输入数据是整形：确定三个有效等价类（正整数、零、负整数），一个无效等价类（非整数）。
   6. 输入条件规定处理的对象是表格：确定一个有效等价类（表格有一项或多项），一个无效等价类（空表）。
   7. ······

3. 设计测试用例

   

   利用等价类设计测试用例的步骤：

   1. 设计一个新的测试用例，使其尽可能多的覆盖尚未覆盖的有效等价类，重复这一步，知道所有的等价类都被覆盖为止。
   2. 为每个无效等价类设计一个新的测试用例。

边界值：指相对于输入等价类胡输出等价类而言，直接在其边界上或稍微高于其边界值或稍微低于其边界值的一些特殊情况。

边界值分析方法选择测试用例的规则：

1. 输入值规定了值的范围：选择刚刚达到这个范围的边界值和刚刚超出这个范围的边界值。
2. 输入条件规定了值的个数：分别选取最大个数、最小个数、比最大个数多1、比最小个数少1的数据。
3. 对每个输出条件使用第1条。例如——输入金额大于且小于10^4，选择金额分别为0、9999、-1、10000
4. 对每个输出条件使用第2条。例如——规定输出的一张发票上，至少有1行内容，至多有5行内容，选择的输入为：1行、5行、0行、6行。
5. 程序的输入或输出是个有序集合：例如——顺序文件、表格，则把注意力集中在有序的第1个元素和最后一个元素上。
6. 程序中定义的内部数据结构有预定义的边界：例如——数组的上界和下界、栈的大小，则应该选择使得正好达到该数据结构边界以及刚好超出该数据结构边界的输入数据作为测试数据。例子：程序中数组A的下界是10，上界是20，则可以选择是的A的下标为10、20、9、21的输入数据作为测试数据。
7. 找出其他可能的边界值。

V模型，4类测试的对象、任务与依据

一种测试策略就是将测试分为单元测试、集成测试、确认测试和系统测试

V模型：描述软件开发各阶段与测试策略之间的对应关系。

1. 单元测试（模块测试）：依据过程设计文档，对软件设计的最小单元进行测试。以发现模块内部的错误。采用的测试方法是白盒测试。
2. 集成测试（组装测试、联合测试）：经单元测试后，每个模块都能独立工作，但集合起来后往往不能正常工作。针对集成的软件系统，揭露设计阶段的错误
3. 确认测试：根据软件需求规约，对集成的软件进行确认，以发现不符合需求规约的错误。
4. 系统测试： 根据系统工程中对软件的要求，对于基于计算机系统中的软件，需将它集成到基于计算机系统中，并进行 系统测试 ，以揭露不符合系统工程中对软件要求的错误根据软件需求（恢复测试、安全保密测试、压力测试、性能测试）

11、软件维护

软件维护的定义与分类（理解）

软件维护的定义：指软件系统交付使用后，为了纠正错误或满足新的需要而修改软件的过程。

软件维护的分类：

1. 纠错性维护：为了改正软件系统中的错误，使软件能够满足预期的正常运行状态的要求而进行的维护。
2. 适应性维护：为了使软件适应内部或外部环境变化，而去修改软件的过程。
3. 改善性维护：满足使用过程中用户提出增加新功能或修改已有功能的建议维护。
4. 预防性维护：为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好的基础而修改软件的活动。

提高软件可维护性的方法（了解）

1. 确定质量管理目标和优先级
2. 使用提高软件质量的技术与工具
3. 选择可维护性高的程序设计语言
4. 完善程序文档
5. 进行质量保证审查

二、题型与答题要点

1. 选择题

2. 判断题

3. 名词解释

4. 简答题

   1. 最忌“答非所问
   2. 是否有“标题”答案，知识点“掌握”与“了解”的区别
   3. 应该有简要的解释
   4. 不要“绕口令”，如教材中关于瀑布模型的阐述****

5. 测试用例设计

   1. *白盒法：基本路径，逻辑覆盖（不同的等级要求）、循环覆盖*
   2. *黑盒法：等级类（包含无效等价类）、边界值*
   3. *答题时，看清楚题目的要求*

6. 结构化分析

   1. *要求：数据流图+数据字典+功能说明*
   2. *数据流图：首先要符合规范*
   3. *数据字典：首先要严谨，其次是注意细节*
   4. *功能说明：用流程图描述处理过程*
   5. *另外，注意写清楚对数据文件的引用与写入的规则*