华南理工大学软件工程复习提纲

1、第一章软件工程概述1 .什么是软件？软件是一系列按照特定顺序组织的计算机数据和指令的集合，包括程序、数据和文档2 .什么是软件危机，其内容主要是指什么？(1)软件危机指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件 开发与维护过程中出现一系列问题的现象。(2)主要表现 开发进度难以预测开发成本难以控制用户对产品功能难以满足产品质量无法保证，难以维护缺少适当的文档资料3 .什么是软件工程？软件工程是应用计算机科学、数学及管理科学等原理开发软件的工程。它借鉴传统工程的 原则、方法，以达到提高软件质量，降低开发成本的目的。4 .软件工程的目标及其组成部分(1)目标：在给定成本、进度

2、的前提下，开发出具有适用性、有效性、可修改性、可靠性、 可理解性、可维护性、可重用性、可移植性、可追踪性、可互操作性和满足用户需求的软 件产品。(2)组成部分方法：是指产生某些结果的形式化过程。工具：是用更好的方式完成某件事情的设备或自动化系统，如各种集成开发环境、编译 工具、测试工具等。过程：生产特定产品的工具和技术的结合5 .软件开发方法的定义软件开发方法是一种使用早已定义好的技术集及符号表示习惯组织软件生产过程的方法。主要有：结构化方法、可视化开发方法和面向对象的开发方法等6 .好的软件的一些主要衡量指标。例如 McCall的质量模型。第二章过程和生命周期建模1 .什么是软件生命周期？主

3、要分为哪些阶段？各个阶段的主要任务及产生的主要制品？(1)软件生命周期是指软件的产生直到报废或停止使用的过程。(2)阶段、任务及制品问题定义：弄清“用户需要计算机解决什么问题”，提出关于“系统目标与范围的说明”，提 交用户审查和确认。可行性研究：了解用户要求和现实环境，从技术、经济、市场等方面研究并论证开发该软件系统的可行性。需求分析：确定用户对待开发软件系统的需求，包括功能、性能、运行环境约束。编写 需求规格说明书和初步的用户手册。概要(总体)设计：根据 SRS建立目标软件系统总体结构、设计全局数据库和数据结构，规定设计约束，制定集成测试计划详细设计：细化概要设计生成的各个模块，详细描述模块

4、的内部细节(算法、数据结构等)，形成可编程的程序模块，制定单元测试计划程序编码：根据详细设计规格说明书编写源程序集成测试：根据概要设计规格说明书，将经过单元测试的模块逐步进行集成和测试确认测试：根据软件需求规格说明书，测试软件系统是否满足用户的需求运行维护：对使用后的软件进行维护，包括修正错误，增加功能，搬迁新环境等性能维护。2 .需求分析的定义。在软件工程中，需求分析指的是在建立一个新的或改变一个现存的电脑系统时描写新系统的目的、范围、定义和功能时所要做的所有的工作。即确定要计算机“做什么”，要达到什么样的效果。3 .典型的软件开发过程模型的特点(优缺点)及要求，特别是原型法、瀑布模型、螺旋

5、模 型、增量和迭代等。一、瀑布模型需求分析一系统分析一程序设计一编码一单元测试和集成测试 一系统测试一验收测试一运行和维护(1)要求：一个开发阶段必须在另一个开发阶段开始之前完成。当客户引发的所有需求都已经过完整性和一致性分析，并形成需求文档之后，开发团队才能够开始进行系统设计活动。每一个过程活动都有与其相关联的里程碑和可交付产品。(2)特点：优点：采用规范的结构化方法；严格规定每个阶段提交的文档；要求每个阶段交出的产品必须经过验证缺点：对如何处理开发中产品和活动的变化没有提供相关指导；将软件开发视为制造而不是创造；创造一个产品没有迭代的活动；需要等待很长的时间、原型法I典睥迎"I:

6、 I 二赘小 1t屈词主如:丽用11dLi原型法是指在获取一组基本的需求定义后，利用高级软件工具可视化的开发环境，快速地 建立一个目标系统的最初版本，并把它交给用户试用、补充和修改，再进行新的版本开发。反复进行这个过程，直到得出系统的“精确解”，即用户满意为止。（1）要求（过程）确定用户的基本需求；构造初始原形；运行、评价、修改原形；形成最终的管理信息系统（2）特点优点：符合人们认识事物的规律，系统开发循序渐进，反复修改，减少开发中的风险和不 确定性；开发周期短，成本相对少。缺点：忽略软件的总体质量和长期的可维护性；开发过程要经过多次反复修改评价，不便 于管理；开发人员易将原型取代系统分析；缺

7、乏规范化的文档资料 适用范围：处理过程明确、简单系统；涉及面窄的小型系统三、阶段化开发：增量和迭代增量开发：需求文档中指定的系统按功能划分为子系统。定义发布时首先定义一个小的功 能子系统，然后在每一个新的发布中增加新功能。迭代开发：一开始就提交一个完整的系统，然后在每一个新的发布中改变每个子系统的功 特点：缩短循环周期，客户可以提前获得一部分系统功能四、螺旋模型螺旋模型的每个迭代都围绕 4个主要活动：计划；确定目标、可选方案及约束；评估可选 方案及风险；开发与测试特点：优点：有利于软件重用，重视软件质量；减少过多测试缺点：风险驱动，需要丰富的风险评估经验；主要适用于内部开发的大规模软件项目;

8、随着迭代次数增加，工作量加大，开发成本增加4 .原型法的特点以及分类：探索型(递增型)原型、实验型(抛弃型)原型和演化型原型。5 .敏捷开发方法和极限编程的特点。(1)敏捷方法强调灵活性在快速、有效开发在软件中的作用相对于过程和工具，更强调个人和交互的价值更喜欢在生产运行的软件上投入时间，而不是在文档的编写上注重客户的合作，而不是合同谈判专注于对变化的反应，而不是创建一个计划而后遵循这个计划(2)极限编程具有强沟通、简化设计和迅速反馈等特点，一般只适合于规模小、进度紧、需求不稳定、开发小项目的小团队。极限编程的核心有4个要点：交流、简单、反馈和勇气。第三章 计划和项目管理1 .了解项目计划和管

9、理的主要内容和常用方法(1)项目计划要列出软件开发要做的主要工作和任务清单，要回答“软件工程项目做什么”强调可调性创造性分析性响应性，用于协调项目编制、指导项目执行。(2)项目管理，就是项目的管理者，在有限的资源约束下，运用系统的观点、方法和理论, 对项目涉及的全部工作进行有效地管理。即从项目的投资决策开始到项目结束的全过程进 行计划、组织、指挥、协调、控制和评价，以实现项目的目标。主要有：阶段化管理、量化管理和优化管理三个方面。2 .软件可行性研究的内容。了解用户要求和现实环境，从技术、经济、市场等方面研究并论证开发该软件系统的可行 性。第四章获取需求1 .了解需求的重要性及需求分析阶段的目

10、标及主要产物。(1)重要性需求在软件开发起到了决策的作用，提供了开发的方向，指明了开发策略缺少需求或需求错误会导致项目开发失败(2)目标及产物了解客户要求 分析系统的数据要求需求规格说明书2 .需求工程包括哪些方面？需求工程包括需求开发和管理，而需求开发又包括：需求获取，需求分析，需求规格说明 和需求验证。3 .需求的类型：功能需求、非功能需求或质量需求、设计约束、过程约束。4 .两种需求文档：需求定义文档和需求规格说明书。5 .需求规格说明书的主要内容。略6 .常用的需求建模表示方法：ER图、事件跟踪、状态机、Petri网、数据流图、用例图和 原型法。第五章UML部分1 .UML的作用：是为

11、软件系统的制品进行描述(specifying )、可视化(visualizing )、构造 (constructing )、3®化(documenting )的种语言。2 .UML中的4+1视图：用例视图，设计视图，进程视图，实现视图，分布视图。用例视图：用来支持软件系统的需求分析，它定义系统的边界，关注的是系统的外部功 能的描述。逻辑视图(设计+进程)：定义系统的实现逻辑，描述实现用例图描述的功能以及设计软 件系统的设计概念。实现视图：描述组成一个软件系统的各个物理部件以各种方式组合起来，构成一个可实 际运行的系统。分布视图：描述软件产品在计算机硬件系统和网络上的安装、分发、分布。

12、3 .UML中的三种扩展机制：构造型 Stereotype ;标记值tagged value;约束constraint.构造型(stereotype):对UML词汇(建模元素)的扩充，用来描述和已有的UML建模元素类似，但又对特定的问题领域有特殊意义的建模元素。(类)标记彳K ( tagged value):对UML建模元素的构成(property)的扩充，用于为此建模元素增 加新的规格说明。(类的属性)约束(constraint):约束用来扩充 UML建模元素的语义，以便增加新的规则或修改已有 的规则(关系)4 .UML中所包含的9种图形及各自的作用。类图：包含类、接口、协同及其关系，用来描

13、述逻辑视图的静态属性。对象图：包含对象及其关系，用来表示类图的类的对象在系统运行过程中某一时刻的状态。组件图：描述系统的物理实现，包括构成软件系统的各部件的组织和关系。类图里的类 在实现时最终会映射到组件图的某个组件。一个组件可以实现多个类。分布图：描述系统的组件在运行时在运行节点上分布，一个节点可包含一个或多个组件。用例图：描述系统的边界和其上的动态行为，包括用例、系统作用者及其之间的关系。序列图和协作图：用来描述一组对象之间的动态交互。状态图和状态机：用来描述对象的动态特性。前者强调对象对外部事件的相应及相应 的状态变迁，后者描述对象之间控制流的转换和同步机制。5 .用例图的作用。用例图用

14、来描述软件需求模型中的系统功能，通过一组用例可以描述软件系统能够给用 户提供的功能。用例图可以作为整个系统开发过程中的开发依据，指导和驱动其他模型。6 .用例图的主要构成部分。参与者用例系统边界关系（箭头）（同言，、-尹柱存运推、U 1 .国 r.rir收Aer为不 ,”住耳_.j < <ihu lu串二./、4¥/预订则产JF 济寇T枪owtitiaZX对间7 .类图的主要作用类图是描述类、接口以及它们之间关系的图，它显示了系统中各个类的静态结构，是一种静态结构。8 .了解类之间的各种关系：关联、依赖、继承或泛化、组合 &聚合关联：用来表示两个（或多个）类的对象

15、之间的结构关系，在代码中表现为一个类以属性的形式包含对类的一个或多个对象的引用。依赖：表示一个类以某种形式依赖于其他类。依赖关系中，其中一个类的改编可能会影 响另一个类。在程序代码中，依赖关系意味着一个类的对象出现在另一个类的操作当中。常见的有两种情况：一个类将另一个类的对象作为自己某个操作的参数（形参） ，或者是操 作的局部变量。泛化（继承）：定义类和包之间的一般元素和特殊元素之间的分类关系。聚合：表示类之间整体与部分的关系。聚合意味着一个类拥有但共享另一个类的对象。组合：特殊形式的聚合。一个部分类最多只属于一个整体类，整体类不存在时，部分类 将同时销毁。9 .了解类图的基本建模步骤10 .

16、接口和抽象类的定义及各自的特点。(1)抽象类抽象类是指那些不具有任何对象的类，其作用是为其他的类描述它们的公共属性和行为。通常，抽象类具有一组抽象操作。一个拥有至少一个抽象操作的类必定是一个抽象类。(2)接口接口是一组没有实现的操作的集合。接口只提供操作的声明，不提供任何相应的功能代码。具体的功能代码由使用该接口的类实现，这叫作实现关系。特点：接口只包含操作而不包含属性，并且操作都是公有的(public),不允许使用可见性限定符。接口不能自己实现其操作，而是由相应的类来实现。接口没有构造函数和析构函数，不能直接被实例化一个类可以实现多个接口。(3)对比接口是一个不带实现的类，它只规定类的外部特

17、性，包括公共属性、操作及其语义，因此只有操作声明而没有方法体和物理存储区。抽象类和接口很相似，也只定义接口而推迟定义其实现部分，然而抽象类允许增加一些 方法的实现。语义层面上：抽象类是一种类是对一组具有相同属性和方法的逻辑上有关系的事物的一种抽象。而接口则是对一组具有相同属性和方法的逻辑上不相关处物的一种抽象。抽象类中可以有自己的数据成员，也可以有非abstract的成员方法。而接口中的方法只能有静态的不能被修改的数据成员抽象类表示的是一种继承关系，一个类只能使用一次继承关系。但是，一个类却可以实 现多个 interface。抽象类中的方法可以有默认行为。但接口中的方法却不能拥有默认行为。11

18、 .交互图的分类：顺序图和协作图，各自的优缺点。UML2.0中协作图改成通信图。交互图描述一个交互，其中包括了一系列的对象及其关系以及通过这些关系在对象之间传送的消息。(1)顺序图强调的是消息发送的时间的先后顺序。对象：序列图中所包含的每个对象用一个对象框(短式)表示，对象名需带下划线。生存线：对象框下画的一条垂直虚线，称为该对象的生存线，表示对象的生存时间。激活期：对象生存线上的一个细长方形框，表示该对象的激活时间段，即活动期间。消息：对象之间消息的发送和接收用两个对象生存线(激活期)之间的消息箭头线。(2)协作图强调的是发送和接收消息的对象之间的组织结构。一个协作图显示了一系列的对象和在这

19、些对象之间的联系以及对象间发送和接收的消息。构成：对象；连接；在此连接上传递的消息(3)对比相同点：它们都表现出了对象之间的交互信息。两个图对象的绘制方式相同不同点：顺序图反映了对象之间交互的时间关系，而通信图反映了对象之间交互的空间关系。顺序图用于展示特定的业务场景，而通信图用来展示详细的业务过程。顺序图的对象在图形的顶部一字排开，而通信图对象的摆放位置在二维空间只要选择合 适的位置即可。通信图不能表现组合片段。12 .状态图和活动图各自的作用。(注意活动图中泳道的作用)(1)状态图状态图描述了一个对象或交互过程在它的生命周期中对一系列外界激励的所呈现出的不同 状态以及它相应的响应和活动。状

20、态图描述交互对对象内部的影响，交互图中的消息在这里变成外部事件对对象发出的命 令，对象对这些命令的响应导致对象的状态发生变化。因此，从这个意义上说，状态图是顺序图的进一步细化，并且是对核心对象(选择核心对象的依据是看是否在多个交互图中 有多个消息指向该对象)的细化。TT(2)活动图在UML里，用来为非反应型对象建模的状态机被称为活动图。活动图是一种特殊形式的状态机，用于对计算流程和工作流程建模。活动图着重表现活动的控制流，描述在对象之间传递的操作泳道：活动图可以用来表达软件对象的比较复杂的动态行为。这些动态行为可能是模拟现实世界的某个机构的各业务部门的运作情况；也可能是一个复杂的算法，这算法可

21、能需要由软件系统中的多个协同共同实现。(协同指的是多个类的对象共同工作，以提供单个类的的对象单独工作不能提供的动态行为)在UML里，对在语义上互相关联的活动状态的子集的划分，是使用泳道 (swim lane)实现的。泳道是活动图里对其中的活动按照其职责上的关联进行的划分。泳道在活动图内是一系 列的垂直的隔断。在活动图里，泳道区分了其中的活动的不同职责。在有泳道的活动图中，每一活动都属于且只属于一个泳道。泳道之间可以有变迁的传递。 泳道从语义上可以理解为是一个模型包。泳道可以有名字，以区分不同状态集合的职责。泳道可以用在为复杂的算法进行建模的活动图上。这时，一个泳道对应于一个协同，其 中的活动可

22、以由一个或多各互相连接的类的对象实现。带有泳道的活动图也可以在软件开发的需求分析阶段用来为业务部门的业务流程的建模 上，这时，泳道可以代表业务流程中的一个业务部门。13 .组件图的作用以及组件与接口间的关系。 组件是一个相对独立的物理块，是系统的一个物理和可替代的组成部分，一般作为一个独 立的文件存在。组件具有确定的借口，相互之间可以调用，组件之间存在依赖关系。 组件图的主要目的是显示系统组件间的结构关系。组件与接口：组件的一个重要特性就是实现了逻辑视图中为软件系统规定的设计词汇的语义，语义除 了静态结构之外，即是其规定的动态行为。从组件外部来看，一个组件区分于另一个组件 的的本质特征就是其动

23、态行为。如果需要强调组件的动态行为，即组件为外部世界提供的 服务，就可以使用接口。通过将软件系统的划分为不同的可执行组件，可以实现软件系统的组件化。软件系统在 物理上由不同组件构成，有些组件向外部提供由接口规定的服务，有些组件使用这些服务。组件化的好处：组件是可替换的；边界清晰；便于维护、升级；组件化的软件系统可以 是分布式的，不要求使所有组件都运行于一个结点一个组件实现了一个接口，被一个组件实现的接口是该组件的实现接口。一个组件使用了另一个组件通过接口提供的服务，被一个组件调用的接口是该组件的输入 接口14 .部署图的作用以及节点的分类（1）部署图（配置图）是用来显示系统中软件和硬件的物理架

24、构。从部署图中，您可以了 解到软件和硬件组件之间的物理关系以及处理节点的组件分布情况。使用部署图可以显示 运行时系统的结构，同时还传达构成应用程序的硬件和软件元素的配置和部署方式。部署图描述了一个运行时的硬件结点，以及在这些结点上运行的软件组件的静态视图。 部署图显示了系统的硬件，安装在硬件上的软件，以及用于连接异构的机器之间的中间件。（2）节点节点是运行时代表计算资源的物理元素。节点通常有内存及处理能力，它可以是物理设备 及运行在该设备上的软件系统。节点分为处理机和设备处理机：能执行软件、具备计算能力的节点，如主机、服务器、客户机等设备：没有计算能力的节点，如打印机、传感器、终端等15.主要

25、的面相对象设计原则及各自的原理：OCP,LSP,DIP,ISP,CARP,LoD设计原则名称简介里氏替换原则LSP任意父类可以出现的地方，子类也可以出现开闭原则OCP对扩展开发，对修改关闭单一职责原则SRPr类的职责单一依赖倒车t原则DIP;针对抽象（或接口）编程，而不针对具体编程接口隔离原则ISP使用多个专门接口要优于使用单一的接口组合聚合原则CRP优先使用组合或聚合关系，不要过于使用继承关系迪米特原则LoD一个软件实体对其他实体的引用越少越好LSP李氏替换原则：如果在任何情况下，子类（或子类型）或实现类与基类都是可以互 换的，那么继承的使用就是合适的。为了达到这一目标，子类不能添加任何父类

26、没有的附加约束。OCP开闭原则：软件实体（类、模块、函数等）应该是可扩展的，但是不可修改的。SRP单一职责原则：规定一个类应该只有一个发生变化的原因。如果一个 类承担的职责过多，就等于把这些职责耦合在一起了。一个职责 的变化可能会削弱或者 抑制这个类完成其他职责的能力。这 种耦合会 导致脆弱的设计，当发生变化时，设计会遭受到意 想不到的破坏。而如果想要避免这 种现象的发生，就要尽可能的遵守 单一职责原则。此原则 的核 心就是解耦和增 强内聚性。ISP接口隔离原则：客户端不应该依赖它不需要的接口； 一个类对另一个类的依赖应该建立在最小的接口上。 为了避免 肥接口（fat inteface）应当以

27、一个 类实现多个接口，而各客 户 仅仅获知必须的接口DIP依赖倒转原则：程序要依赖于抽象接口，不要依赖于具体实现。简单的说就是要求对抽象进行编程，不要对实现进 行编程，这样就降低了客 户与实现模块间的耦合。CRP组合复用原则：继承复用：实现简单，易于扩展。破坏系统的封闭性，从基类继承而来的实现是静态的，不能在运行时动态改变，缺乏灵活性（即“白盒” 复用）。组合/聚合复用：耦合度较低，可以灵活地选择成员对象的操作；可以在运行时动态改变。（即“黑盒”复用）迪米特原则：指一个软件实体应该尽量少与其他实体发生相互作用。16 .设计模式的内容和分类。（1）设计模是一套被反复使用、多数人知晓的、经过分类编

28、目的、代码设计经验的总结。一个模式有四个基本要素：模式名称、问题、解决方案、效果（2）分类创建型模式：抽象的实例化过程，隐藏了对象创建的具体细节，使程序代码不依赖具体 的对象。例：单例模式、抽象工厂模式、建造者模式、工厂模式、原型模式。结构型模式：描述类和对象之间通过组织形成新的结构，以实现新的功能。例：适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式。行为型模式：描述算法以及对象之间的任务（职责）分配及它们之间的通讯模式。例：模版方法模式、命令模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解 释器模式、状态模式、策略模式、职责链模式、访问者模式。17 .设计模式

29、与面向对象设计原则之间的关系，特别是 OCP原则设计模式就是实现了面向对象原则，从而达到了代码复用、增加可维护性的目的。18 .了解常见设计模式的设计思想及其原理，了解如何从 OCP的角度进行分析第六章设计系统1 .概念设计和技术设计的内容概念设计：是由分析用户需求到生成概念产品的一系列有序的、可组织的、有目标的设 计活动，它表现为一个由粗到精、由模糊到清晰、由抽象到具体的不断进化的过程。技术设计：对主要硬件部分及其功能的描述，确定设计软件构件的层次和功能、数据结 构和数据流2 .好的设计的衡量：内聚和耦合内聚是一个模块内部各成分之间相关联程度的度量。(高内聚)耦合是指对象之间的依赖性(低耦合

30、)，耦合性是程序结构中各个模块之间相互关联的度 量。它取决于各个模块之间的接口的复杂程度、调用模块的方式以及哪些信息通过接口。3 .常用的内聚和耦合度类型(1)内聚类型低一高：功能内聚、信息内聚、通信内聚、过程内聚、时间内聚、逻辑内聚、偶然内聚(2)耦合类型高一低：内容耦合、公共耦合、外部耦合、控制耦合、标记耦合、数据耦合、非直接耦合第七章测试1 .测试的目标和衡量标准目标：发现错误，只有当发现了错误时，测试才被认为是成功的。衡量标准：需求的覆盖率；缺陷数量；缺陷重现率；效率；重用价值。2 .测试的分类(或组织)。各种类型的测试的主要任务及所依赖的文档。模块、构件、单元测试：对软件中的最小可测

31、试单元进行检查和验证，目的是检验软件 基本组成单位的正确性。集成测试：在单元测试的基础上，将所有模块按照设计要求组装成为子系统，进行集成 测试。目的是检查软件单位之间的接口是否正确。功能测试：对产品的各功能进行验证，根据功能测试用例，逐项测试，根据需求文档检 查产品功能完整性。性能测试：检查系统的响应速度，结果精确性和数据的可访问性验收测试：指确认系统是否符合设计规格或契约之需求内容的测试安装测试：确保该软件在正常情况和异常情况的不同条件下，安装后的正常运行。3 .黑盒测试和白盒测试的思想，了解白盒测试中的基本路径测试等方法。(1)黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使

32、用。在测试中, 把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在 程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是 否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑 内部逻辑结构，主要针对软件界面和软件功能进行测试。(2)白盒测试又称结构测试，是全面了解程序内部逻辑结构、对所有逻辑路径进行的测试。 "白盒"法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查 程序的逻辑着手，得出测试数据。(3)基本路径测试基本路径测试法是在程序控制流图的基础上，通过分析控制构造的环

33、路复杂性，导出基本 可执行路径集合，从而设计测试用例的方法。设计出的测试用例要保证在测试中程序的每 个可执行语句至少执行一次。在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例。4 .单元测试的主要内容。包括模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试5 .集成测试的类型及主要的测试策略。（1）类型自底向上：从软件结构中最底层、最基本的软件单元开始进行集成和测试自顶向下：一个模块一个模块地集成软件，按照控制的结构，从主控模块开始，向下逐个 把模块连结起来。一次性测试；三明治测试：混合上下（2）策略非增量式：先测试好每一个软件单元，

34、然后依次集成在一起再测试整个程序。增量式：逐步把一个要被集成的软件单元或不见，同已测试好的软件部件结合起来测试。 好处：占用人工、时间少，能较早发现模块错误，利于并行开发。6 .确认测试的内容。包括：安装测试、功能测试、性能测试、安全性测试、兼容性测试、可使用性测试、文档 测试7 .了解测试计划的主要内容。测试计划，描述了要进行的测试活动的范围、方法、资源和进度的文档；是对整个信息系 统应用软件组装测试和确认测试。它确定测试项、被测特性、测试任务、谁执行任务、各 种可能的风险。测试计划可以有效预防计划的风险，保障计划的顺利实施。8 .测试系统中的测试过程：功能测试、性能测试、验收（确认）测试、

35、安装测试，及他们 的内容第八章系统维护1 .维护活动的类型：改正性、适应性、完善性、预防性2 .各种维护活动的主要内容和目标改正性维护（17%-21%:改正在系统开发阶段已发生而系统测试阶段尚未发现的错误。适应性维护（18%-25% :指使用软件适应信息技术变化和管理需求变化而进行的修改。完善性维护（50%-60%:为扩充功能和改善性能而进行的修改，主要是指对已有的软 件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。另外还包括处理效 率和编写程序的改进。预防性维护（4%）:为了改进应用软件的可靠性和可维护性，适应未来软硬件环境的变化，主动增加预防性的新的功能。3 .软件再生：文档重构、重组、逆向工程、再工程，以及它们各自的内容和含义。文档重构：对源代码进行静态分析，给出更多的信息重组：改变代码结构逆向工程：根据代码重新创建设计和规格说明信息再工程：对现有工程进行逆向工程，接着再改