软件工程基础知识点总结 第1篇

（1） 源程序：包括适当的标识符、适当的注解、程序清单的合理布局与清晰；

（2) 数据说明:数据结构或数据类型的说明次序标准化；变量名称尽量有意义;对复杂的数据结构在注解中要说明在程序设计中实现这个数据结构的方法.

（3） 语句的构造简单明了：不要为节省空间将多个语句写在同一行；尽量避免复杂的条件及“非”条件的测试；避免大量使用循环嵌套和条件嵌套；括号的使用是为了使逻辑表达式和算术表达式的运算顺序清晰直观。

（4) 效率:考虑程序运行的时间存储器效率、输入/输出的效率；在处理程序正确性、清晰与效率之间的关系时先求程序正确后求快；先求清楚后求快；保持程序简单以求快；书写清楚，不为“效率”牺牲清晰.

软件工程基础知识点总结 第2篇

开发方法：采用模块化详细设计文档有助于理解软件的结构、界面功能和内部流程；开发过程中严格而科学的管理规划及清晰可靠的文档资料对发生错误后的理解与纠错是至关重要的；开发过程中模块的独立程度越高，对软件修改越容易，对软件的改进和移植越方便.

开发条件：软件开发及维护人员的水平决定了软件开发的质量和维护的效率；开发过程中使用标准的程序设计语言和标准的操作系统接口，可以大大提高软件的可维护性；在测试过程中用例的有效性,可极大地减少软件存在的错误；其次使用规范化的文档资料可为维护提供更好的依据。

软件工程基础知识点总结 第3篇

软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合。

软件危机（Software Crisis）：指由于落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。 (1) 软件开发计划难以制订。 (2) 软件开发费用和进度失控。 (3) 软件产品无法让用户满意。 (4) 软件产品的质量难以保证。 (5) 软件通常没有适当的文档资料。 (6) 软件通常是不可维护的。 (7) 软件成本在计算机系统总成本中所占比例逐年上升。

方法、工具、过程

在给定成本、进度的前提下，开发出满足用户需求且具有 可修改性、有效性、可靠性、可理解性、可维护性、可重用性、可适应性、可移植性、可追踪性和可互操作性 的软件产品。

软件工程基础知识点总结 第4篇

软件开发模型有瀑布型、渐增型和变换型.

瀑布型开发方法是按照软件生存周期的划分依次实施，每一个阶段有明确规定的任务。它的特点:

(1）各个阶段的顺序性和依赖性；

(2）划分逻辑设计与物理设计，尽可能推迟程序的物理实现;

(3)每个阶段必须完成规定的文档，对其中问题通过复审及早发现,及早解决.

渐增型开发方法及特点:

(1） 从部分需求出发，先建立一个不完全的系统，通过测试运行该系统取得经验和信息反馈，加深对软件需求的理解，进一步使系统扩充和完善.如此反复，直至软件人员和用户对所设计完成的软件系统满意为止.

（2） 在渐增型开发下的软件是随软件开发的过程而逐渐形成的。

（3) 渐增型开发方法适合于知识型软件的开发，设计系统时对用户需求的认识开始不是很清楚的，需要在开发过程中不断认识、不断获得新的知识去丰富和完善系统。多数研究性质的试验软件，一般采用此方法。

变换型开发方法及特点:

(1)从软件需求的形式化说明出发，经过一系列的程序变换,得到最终的程序系统。

(2）该方法必须有严格的数学理论和形式化技术的支持。

软件工程基础知识点总结 第5篇

（1) 在DFD图中确定事务中心、接收部分（包含全部接收路径）和发送部分（包含全部动作路径）；

（2） 画出SC图框架,把DFD图的三部分分？quot；映射_为事务控制模块，接收模块和动作发送模块。一般得到SC图的顶层和第一层（如果第一层简单可以并入顶层）；

（3) 分解和细化接收分支和动作分支,完成初始的SC图；

(4) 对初始结构图按照设计准则进行精化与改进。

软件工程基础知识点总结 第6篇

提纲 UML概述 UML中的图 面向对象分析概述 用例建模 创建领域模型 绘制系统顺序图 创建系统操作契约

UML：统一建模语言 ，UML 是一种标准的图形化建模语言，它是面向对象分析与设计的一种标准表示。

1. UML的目标 为建模者提供现成的、易用的、表达能力强的可视化建模语言，以开发和交换有意义的模型； 提供可扩展性和特殊化机制以延伸核心概念； 与具体的实现无关，可应用于任何语言平台和工具平台； 与具体的过程无关，可应用于任何软件开发的过程； 支持更高级的开发概念，例如构件、协作、框架和模式，强调在软件开发中对架构、框架、模式和构件的重用（UML 规范）； 与最好的软件工程实践经验集成； 可升级，具有广阔的适用性和可用性； 推动对象工具市场的成长。

2. UML的视图和图 五类不同视图：

每一种UML的视图都是由一个或多个图组成的：

视图和组成视图的图之间的对应关系：

用例方法是当今广泛使用的用于发现和记录系统功能性需求的方法

**用例的主要思想是：**以用户目标（即用户希望系统能为他带来哪些有价值的结果）为出发点去考虑系统的功能和特性，并用用例进行描述，专注于考虑系统怎么才能增加价值和实现用户目标。

用例将系统的特性和功能放到面向用户目标的语境中去考虑，从而能使识别出来的功能是真正为用户提供价值的功能。

UML类图用于描述类以及类之间的关系

类之间关系的表示 UML中类之间的关系可分为：依赖、关联、聚合、组合和继承

（1）依赖 依赖是一种使用的关系，即一个类的实现需要另一个类的协助，所以依赖关系通常是单向的。UML中使用带箭头的虚线表示依赖关系。

依赖具有偶然性、临时性，是非常弱的关系。简单理解就是类A使用到了类B，使用完毕后关系解除。

代码表现：方法参数、局部变量、静态方法的调用

（2）关联 关联是一种拥有的关系，它使一个类知道另一个类的属性和方法，是一种长期性、相对平等的关系

关联可以有双向(实线)和导航(单向箭头)，关联的两端可以标注重数(基数)，表示类之间的数量对比关系

代码表现：成员变量

关联类：和类一样，关联也可以有自己的属性和操作。此时，这个关联实际上是个关联类（association class）

（3）聚合（aggregation） 聚合是表示整体的类和表示部分的类之间的**“整体–部分”关系**，是一种强类型的关联。在聚合关系中，把作为**“整体”的类称为聚集（aggregate），作为“部分”的类称为成分** 聚合关系中的整体和部分之间用带空心菱形箭头的连线连接，箭头指向整体。

（4）组合（composition） 组合是更强类型的聚合，要求部分的生存周期取决于整体的生存周期，部分不能脱离整体而单独存在，每个部分只能属于一个整体。 除了菱形是实心之外，组合和聚合的表示法相同

（5）继承（generalization） 继承也称泛化，是面向对象描述类之间相似性的一种重要机制 父类与子类的泛化（generalization）关系图示为一个带空心三角形的直线，空心三角形紧挨着父类。

多层继承

多态 polymorphism

复杂类图

类关系由弱到强次序及表示

类图表示类以及类之间的关系，对象图表示在某一时刻类的具体实例和这些实例之间的具体连接关系。

顺序图是一种详细表示对象之间以及对象与参与者之间交互的图，它由一组协作的对象（或参与者）以及他们之间可发送的消息组成，强调消息之间的顺序。 顺序图是二维的，其中，垂直方向表示时间，水平方向表示不同的对象或参与者。

协作图是一种强调发送和接收消息的对象结构组织的交互图，显示围绕对象以及它们之间的链而组织的交互。 协作图由对象、链以及链上的消息构成，其中也可以有参与者。

协作图有两点不同于顺序图： 协作图有链和消息序号。

顺序图和协作图可以相互转换，而不丢失语义信息，因为这两种图都共享相同的基本模型。它们统称为类和对象的 “交互图” 。

1. 什么是OOA **面向对象分析（Object-Oriented Analysis，简称OOA）**就是运用面向对象的方法进行系统分析，是软件生命周期的一个阶段，具有一般分析方法共同具有的内容、目标及策略，强调运用面向对象方法，对问题域和系统职责进行分析和理解，找出描述问题域及系统职责所需的对象，定义对象的属性以及它们之间的关系，目标是建立一个符合问题域、满足用户需求的OOA模型。

2. OOA与OOD的职责划分 OOA针对现实世界中的问题域与系统职责，用面向对象的方法建立起针对问题域和系统职责的模型，作为分析的结果。 OOA模型不考虑与系统的具体实现相关的因素，独立于具体的实现环境。

OOD则是针对系统的具体实现，运用OO方法进行系统设计。 一是根据实现条件对OOA模型做某些必要的调整和修改，使其成为OOD模型的一部分 二是针对具体实现条件，建立人机界面、数据存储和控制驱动等模型。

3. OOA过程 主要包括以下活动：

用例建模的基本过程： 第1步．确定系统边界。 第2步．识别主要参与者。 第3步. 根据主要参与者目标，识别和定义用例。

用例之间的关系有包含关系、扩展关系和继承关系，在此重点介绍前两种关系。

（1）包含关系(include) 一部分行为经常会出现在多个用例中，为了避免重复，可以创建一个子功能级别的用例，并让其他的用例包含它。 一个用例可以包含多个用例，一个用例也可被多个用例包含。

（2）扩展关系(extend) 问题：由于某种原因已有的用例文本不能被修改（例如该用例文本已经是基线），但是可能又要为种种新的扩展场景和条件步骤不断修改用例

使用扩展关系可以解决这个问题。其思路是创建一个扩展或附加用例，在该用例中描述在什么情况下，从基用例什么地方开始扩展基用例的行为

使用场合：（多个）基本用例中的某些场景存在相同的条件判断的情况，可以将其抽取出来作为基本用例的子用例；

用例描述 对用例的描述，可以用自然语言，也可以采用用户自定义的语言。 为了更清楚地说明问题，也可以采用面向对象的类图、交互图、状态图或活动图来做进一步的描述。由于现在还只是需求分析阶段，只是在概念上使用这些图。

例如用活动图描述：

（1）定义 领域模型：针对某一特定领域内概念类或者对象的抽象可视化表示。

主要用于概括地描述业务背景及重要的业务流程，并通过UML的类图和活动图进行展示，帮助软件开发人员在短时间内了解业务。

（2）创建步骤 领域模型的创建步骤如下： 第1步 识别或抽象出领域的概念类或对象； 第2步 建立概念类之间的关系； 第3步 设置概念类的关键属性。

一个系统顺序图用来表示在用例的一个特定场景中，外部参与者产生的事件、事件的顺序以及系统之间的事件。

在系统顺序图中，所有的系统都被当作黑盒，图的重点是描述参与者和系统之间、或者系统和系统之间的事件，因此称这些事件为系统事件。系统事件对于理解系统要具备怎样的行为是很有帮助的。

系统事件通常是参与者主动向系统发出的。为了识别系统事件，需要从用例的主要成功场景以及频繁或复杂的替代场景中寻找系统事件，建立系统顺序图。

可以使用UML的顺序图来描述系统顺序图，但不是它的主要用途

系统事件的发生将会触发系统操作，系统操作可以通过发现系统事件来识别。 系统操作使用和系统事件相同的名字，以明确表示是哪个系统事件引发的该系统操作。系统操作的参数同系统事件。

创建契约的指导原则：

软件工程基础知识点总结 第7篇

Jackson与LCP设计方法都是以数据结构为出发点，以程序的过程描述为最终目标,设计步骤基本相似。它们的主要差别是:

（1)使用不同的表达工具，其中LCP方法中的表达工具Warnier图

      比Jackson设计方法中的表达工具Jackson图有更大的通用性;

（2)Jackson方法的步骤和指导原则有一定的灵活性，而LCP设计

      方法则更加严密.

软件工程基础知识点总结 第8篇

相同点：

（1)  遵守结构程序设计“由顶向下”逐步细化的原则，并以其为共同的基础；

（2）  均服从“程序结构必须适应问题结构”的基本原则，各自拥有从问题结构（包括数据结构)导出程序结构的一组映射规则。

不同点:

(1)  面向数据流的设计以数据流图为基础，在分析阶段用DFD表示软件的逻辑模型，在设计阶段按数据流类型,将数据流图转换为软件结构。面向数据结构的设计以数据结构为基础，从问题的数据结构出发导出它的程序结构。

(2)  面向数据流的设计的最终目标是软件的最终SC图，面向数据结构的设计的最终目标是程序的过程性描述。

软件工程基础知识点总结 第9篇

（1） 选择用户熟悉、便于用户维护的语言。

(2） 选择目标系统的环境中可以提供的编译程序所能选用的语言。

（3） 选择可以得到的软件工具,能支持程序开发中可以利用的语言。

(4) 根据工程规模的大小、目标系统应用范围,如实时应用选择Ada语言或汇编语言，系统软件开发选择C语言或汇编语言,软件开发中若含有大量数据操作则选择SQL、dBASE等数据库语言等。

（5） 选择程序员熟悉的语言.

(6) 选择标准化程度高、程序可移植性好的语言。

（7) 根据算法与计算的复杂性、数据结构的复杂性选择。如对于系统程序和结构复杂的应用程序,选择支持数组、记录（或结构）与指针动态数据结构的Pascal语言或C语言。

(8) 根据实时要求系统需要的响应速度和效率选择相应的语言。

软件工程基础知识点总结 第10篇

(1） 费用管理: 对软件开发进行成本核算，使软件生产按照商品生产的规律办事.包括:以简单、科学方法估算软件开发费用，作为签定开发合同的根据；管理开发费用的有效使用,即用经济手段来保证产品如期按质完成。

(2) 质量管理: 按项目的质量保证计划,确保各个开发阶段的开发和维护工作全部按软件工程的规范进行,保证软件产品的质量。

(3） 配置管理:通过对于程序、文档和数据的各种版本所进行的管理,保证资料的完整性与一致性。

（4) 项目管理：制定《项目实施计划》，按照计划的内容组织和实施软件的工程化生产。最终目标是以合理的费用和进度,圆满完成计划所规定的软件项目。

软件工程基础知识点总结 第11篇

（1) 具有很强的数据管理能力，能对数据库进行有效的存取、查询和其它有关操作;

(2） 能提供一组高效的、非过程化的命令，组成语言的基本语句,编程时用户只需用这些命令说明“做什么”,不必描述实现的细节；

（3) 能满足多功能、一体化的要求.为此，语言中除必须含有控制程序逻辑与实现数据库操作的语句外，还应包括生成与处理报表、表格、图形,以及实现数据运算和分析统计功能的各种语句，共同构成一个一体化的语言,以适应多种应用开发的需要。

软件工程基础知识点总结 第12篇

编写软件的“详细设计说明书”。软件人员要完成的工作：

(1）  为每一个模块确定采用的算法， 选择某种适当的工具表达算法的过程,写出模块的详细过程描述.

（2)  确定每一模块使用的数据结构。

(3）  确定模块结构的细节，包括对系统外部的接口和用户界面，对系统内部其它模块的接口，以及关于模块输入数据、输出数据及局部数据的全部细节。

（4）  为每一个模块设计出一组测试用例，以便在编码阶段对模块代码（即程序)进行预定的测试。

软件工程基础知识点总结 第13篇

1. 什么是OOD 面向对象的设计就是在OOA模型基础上运用面向对象方法进行系统设计，目标是产生一个符合具体实现条件的面向对象设计（OOD）模型。

OOA和OOD采用一致的表示法，使得从OOA到OOD不存在转换，只需要做必要的修改和调整，或补充某些细节，并增加几个与实现有关的相对独立的部分。

2. OOD主要工作

软件体系结构设计在用例实现方案设计之前进行，用户界面设计和其他两项工作之间无明显的先后次序关系

OOD的成果是以UML包图等表示的软件体系结构、以交互图和类图表示的用例实现、针对复杂对象的状态图和用以描述流程化处理过程的活动图等。

软件体系结构是描述某一特定应用领域中系统组织方式的惯用模式。

层次化的设计模型是面向对象方法基于软件体系结构风格的一种方案选择。它把软件设计组织成为类或组件的层次/集合，这些类或组件一起完成某一常见的目的，并使系统易于扩展和维护。

软件分层的好处：

软件分层的原则： 层应该是模块化的。应该能够xxx—层，或对整个层进行替换，只要接口保持不变，系统的其他部分应该不受影响。这将有助于系统易于扩展和维护，并增加软件的可移植性。

UML中用包图来描述层。常用的面向对象软件设计的五层软件分层结构如下：

1. 用户界面层 用户界面类实现了系统的主要用户界面元素 把用户界面类从业务领域类中分离出来，就可以使用我们选择的任何方式改变用户界面

用户界面层的实现要点：任何系统的用户界面能够以多种可能的形式出现，然而底层的业务逻辑却保持不变。

2. 控制器/处理层 控制器／处理类作为完成用例任务的责任承担者，用于协调、控制其他类共同完成用例规定的功能或行为

对于比较复杂的用例，控制器/处理类并不处理具体的任务细节，但是它应知道如何去分解任务、如何将子任务分派给其他的辅助类（如业务/领域类甚至其他控制器／处理类）、以及如何在辅助类之间进行消息传递和协调。

相似的用例可以共享同一个控制器类

简单的用例可以不设控制器类，直接在用户界面类中设置控制、协调功能

3. 业务/领域层 业务/领域类实现与业务领域相关的概念，源于领域模型，如“学生”或“试卷”。它着眼于业务对象数据方面的因素，加上单个对象相关的行为。

在OOA阶段关注的是问题域中概念的本质含义以及属性，在OOD阶段将会对这些概念增加操作，并进行必要的修改和调整，使之成为设计模型中业务/领域层中的类。

4. 持久化层 持久类把永久存储、检索、更新和删除对象的能力封装起来，使底层的存储技术不暴露出来。

持久层封装对永久存储介质的访问，但其本身并不是永久存储机制。

引入持久层的目的在于当数据存储机制或策略发生变化的时候，能减少维护工作。无论持久存储策略如何变化，业务/领域类都不会受影响，从而增加了应用程序的可维护性、可扩展性和可移植性。

5. 系统层 系统类为应用提供操作系统相关的功能，通过把特定于操作系统的特性包装起来，使软件与操作系统分离，这样增加了应用的可移植性。

系统类通过使用面向对象代码将操作系统提供的功能进行包装，封装了非面向对象功能。

系统类位于软件开发中的最低层，其他各层的类都可以向系统类发送消息，但是系统类只被允许向其他的系统类发送消息。在完成其工作的过程中，一般不需要知道关于业务逻辑和用户界面逻辑的任何信息。

在SRP中，将职责定义为“变化的原因”。 在构造对象时，应该将对象的不同职责分离至两个或多个类中，确保引起该类变化的原因只有一个，从而提高类的内聚度。

应用OCP原则设计出的模块具有两个主要的特征，它们是：

LSP做为一个检查工作来测试继承是否正确 如果没有LSP，类继承就会混乱；如果子类作为一个参数传递给方法，将会出现未知行为； 如果没有LSP，适用于基类的单元测试将不能成功用于测试子类；

在应用程序中所编写的大多数具体类都是不稳定的。我们不想直接依赖于这些不稳定的具体类。通过把它们隐藏在抽象接口的后面，可以隔离它们的不稳定性 如果一个具体类不太会改变，并且也不会创建其他类似的派生类，那么依赖于它并不会造成损害。

本质：如果一个服务器类为多个客户类提供不同的服务，那么，服务器类应该为每一个客户类创建特定的业务接口，而不要为所有客户类提供统一的业务接口，除非这些客户类请求的服务相同。 向一个客户提供超过客户要求的服务承诺，会给服务提供方带来不必要的维护负担

实现复用时应首先使用组合/聚合(黑盒复用)，其次才考虑继承(白盒复用)。 在使用继承时，要严格遵循LSP原则。 如果两个类具有“has-a”关系则应使用组合/聚合，如果具有“is-a”关系则可使用继承。

符合下列条件的对象即为朋友：

软件工程基础知识点总结 第14篇

（1） 开发人员方面，对软件产品缺乏正确认识，没有真正理解软件产品是一个完整的配置组成.造成开发中制定计划盲目、编程草率，不考虑维护工作的必要性。

(2） 软件本身方面,对于计算机系统来说，软件是逻辑部件,软件开发过程没有统一的、公认的方法论和规范指导,造成软件维护困难.

（3） 尤其是随着软件规模越来越大,复杂程度越来越高，原有软件开发方式效率不高、质量不能保证、成本过高、研制周期不易估计、维护困难等一系列问题更为突出,技术的发展已经远远不能适应社会需求。

软件工程基础知识点总结 第15篇

软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。这

些问题表现在以下几个方面:

(1)用户对开发出的软件很难满意。

(2）软件产品的质量往往靠不住。

（3）一般软件很难维护.

（4)软件生产效率很低。

(5)软件开发成本越来越大。

（6）软件成本与开发进度难以估计。

（7）软件技术的发展远远满足不了计算机应用的普及与深入的需要.

软件工程基础知识点总结 第16篇

软件工程是指导计算机软件开发和维护的工程学科。

（1) 它采用工程的概念、原理、技术和方法来开发和维护软件;

（2） 它将管理技术与当前经过时间考验的而证明是正确的技术方法结合起来；

（3） 它强调使用生存周期方法学和结构分析和结构技术;

（4） 经过人们长期的努力和探索，围绕着实现软件优质高产这个目标,从技术到管理两个方面做了大量的努力，逐渐形成了”软件工程学”这一新的学科.

软件工程基础知识点总结 第17篇

（1)  测试从一个侧面证明程序员的失败；调试证明程序员的正确;

（2)  测试从已知条件开始,使用预先定义的程序，且有预知的结果，不可预见的仅是程序是否通过测试；调试从不可知内部条件开始，除统计性调试外，结果是不可预见的;

（3）  测试有计划并且要进行测试设计；调试不受时间约束；

（4)  测试是发现错误、改正错误、重新测试的过程;调试是一个推理的过程;

（5）  测试执行是有规程的；调试执行要求程序员进行必要的推理；

(6）  测试由独立的测试组在不了解软件设计的件下完成；调试由了解详细设计的程序员完成;

(7)  大多数测试的执行和设计可由工具支持；调试用的工具主要是调试器。

软件工程基础知识点总结 第18篇

(1） 软件项目与其他任何产业项目不同,它是算法、思想、概念、组织、流程、效率、优化等的融合体；

(2) 开发软件项目产品，在多数情况下,用户给不出明确的想法和要求。

（3） 在开发过程中，程序及其相关的文档资料常常需要修改,在修改过程中又可能带来新的问题,且这些问题要在很久以后才会发现.

(4) 在研制开发过程中，文档资料是不可缺少的，但工作量又是巨大的，往往也是人们不愿去作的。

(5) 参加软件项目的工作人员,要求具有一定的业务水平和实际工作经验，而很难完全避免的人员流动，对工作的影响是很大的。离开的人员不仅带走了重要的信息，而且带走了工作经验.

软件工程基础知识点总结 第19篇

提纲 软件实现 软件测试基础 软件测试方法与技术 软件测试过程 软件维护

从宏观上讲，软件实现包括详细设计、程序编码、单元测试和集成测试。 从微观上来讲，软件实现指程序编码和单元测试。

1. 软件实现的目标 软件实现的目标就是选择某种程序设计语言，将详细设计结果进行编码实现，并形成可执行的软件系统的过程。

2. 软件实现的任务

(1) 软件测试的定义(早期和狭义的定义)

(2) 软件测试的目的

设计测试的目标是想以最少的时间和人力系统地找出软件中潜在的各种错误和缺陷。 测试不能表明软件中不存在错误，它只能说明软件中存在错误。

(3) 软件测试的原则 应当尽早地和不断地进行软件测试。 测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成。 程序员应避免测试自己的程序。 在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。 充分注意测试中的群集现象。 严格执行测试计划，排除测试的随意性。 应当对每一个测试结果做全面检查。 妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。

软件的可测试性就是一个计算机程序能够被测试的容易程度。

在软件开发过程中，很多环节都能够影响软件的可测试性，例如需求分析的描述、设计架构、实现手段等

如果设计人员和程序员乐于完成一些对测试过程有帮助的工作，则可以极大提高软件的可测试性

软件测试并不等于程序测试，现代软件测试指为发现软件中存在的错误，对软件开发过程中形成的各项输出进行检查的过程。

测试应该贯穿于软件开发的整个期间，需求分析规格说明、概要设计说明、详细设计说明、单元代码、集成的系统以及其他输出文档，都应该成为测试的对象。

广义的软件测试包含三类具体活动：

测试过程需要三类输入：

6. 软件测试与软件开发各阶段的关系 软件开发过程是一个自顶向下，逐步细化的过程，而测试过程则是依相反的顺序安排的自底向上，逐步集成的过程。低一级测试为上一级测试准备条件。

1. 测试技术分类

常用的测试分类和测试用例设计方法

(1) 黑盒测试 黑盒测试又叫做功能测试、数据驱动测试或基于规格说明的测试，指在不考虑程序内部结构和内部特征的情况下，根据软件产品的功能设计规格说明，在计算机上进行测试，以证实每个实现了的功能是否符合要求。

黑盒测试主要是为了发现以下几类错误：

(2) 白盒测试 白盒测试又称为结构测试、逻辑驱动测试或基于程序的测试，指根据软件产品的内部工作过程，在计算机上进行测试，以证实每种内部操作是否符合设计规格要求，所有内部成分是否已经过检查。

白盒测试方法主要对程序模块进行如下检查：

无论黑盒测试还是白盒测试，如果实行穷举测试，由于工作量过大，实施起来是不现实的，需要精心地挑选少量的测试数据，使得采用这些测试数据能够达到最佳的测试效果。

2. 白盒测试技术 (1) 逻辑覆盖 逻辑覆盖是以程序内部的逻辑结构为基础的设计测试用例的一种白盒测试技术。 逻辑覆盖可分为：语句覆盖、判定覆盖、条件覆盖、判定－条件覆盖、条件组合覆盖及路径覆盖。

语句覆盖(点覆盖)：设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。 A=2，B=0，X=4，即达到了语句覆盖

判定覆盖(分支覆盖)：设计若干个测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次。 A=3，B=0 ，X=3 可覆盖a、c、d分支 A=2，B=1 ，X=1 可覆盖a、b、e分支

条件覆盖：设计若干个测试用例，运行被测程序，使得程序中每个判断的每个条件的可能取值至少执行一次。 A=1，B=0 ，X=3，满足条件 T1(假)，T2 (真)，T3 (假) ， T4 (真) ，可覆盖a、b、e分支 A=2，B=1 ，X=1，满足条件 T1 (真) ，T2 (假) ，T3 (真) ， T4 (假) ，还是覆盖a、b、e分支

判定－条件覆盖：设计足够的测试用例，使得判断中每个条件的所有可能取值至少执行一次，同时每个判断本身的所有可能判断结果至少执行一次。 A=2，B=0 ，X=4，满足条件 T1(真)，T2 (真)，T3 (真) ，T4 (真) ，可覆盖a、c、e分支 A=1，B=1 ，X=1，满足条件 T1(假)，T2 (假)，T3 (假) ，T4 (假) ，覆盖a、b、d分支

多重条件覆盖：设计足够的测试用例，运行被测程序，使得每个判断的所有可能的条件取值组合至少执行一次。 A=2，B=0 ，X=4，满足条件 T1(真),T2(真),T3 (真) , T4 (真) ，覆盖a、c、e分支 A=2，B=1 ，X=1，满足条件 T1(真),T2(假),T3 (真) , T4 (假) ，覆盖a、b、e分支 A=1，B=0 ，X=2，满足条件 T1(假),T2(真),T3 (假) , T4 (真) ，覆盖a、b、d分支 A=1，B=1 ，X=1，满足条件 T1(假),T2(假),T3 (假) , T4 (假) ，覆盖a、b、d分支

路径测试：设计足够的测试用例，覆盖程序中所有可能的路径, 这是最强的覆盖准则。 A=2，B=0 ，X=4，满足条件 T1(真)，T2 (真)，T3 (真) ， T4 (真) ，覆盖a、c、e分支 A=3，B=0 ，X=1，满足条件 T1(真)，T2 (真)，T3 (假) ， T4 (假) ，覆盖a、c、d分支 A=1，B=1 ，X=2，满足条件 T1(假)，T2 (假)，T3 (假) ， T4 (真) ，覆盖a、b、e分支 A=1，B=1 ，X=1，满足条件 T1(假)，T2 (假)，T3 (假) ， T4 (假) ，覆盖a、b、d分支

(2) 基本路径测试 真正做到完全路径覆盖是很困难的，必须把覆盖路径数目压缩到一定限度。如果把覆盖的路径数压缩到一定限度内，例如，程序中的循环体只执行零次和一次，就称为基本路径测试 。

设计出的测试用例要保证在测试中，程序的每一个可执行语句至少要执行一次。

基本路径测试步骤：

步骤1：导出程序的控制流图 控制流图是描述程序控制流的一种图示方法。基本控制构造的图形符号如下所示：

边和结点圈定的区域叫做区域，当对区域计数时，图形外的区域也应记为一个区域。

如果判定中的条件表达式是复合条件时，即条件表达式是由一个或多个逻辑运算符（OR，AND，NAND，NOR）连接的逻辑表达式，则需要改复合条件的判定为一系列只有单个条件的嵌套的判定。

步骤2：计算程序环路复杂性 通常环路复杂性可用以下三种方法求得。

上图所示控制流图环路复杂度为4，因为： 控制流图有4个区域 控制流图边数和点数满足 E-N+2=11-9+2=4 控制流图判定结点数为3, 复杂度=3+1=4

步骤3：确定基本（独立）路径集 程序的环路复杂性给出了程序基本路径集合中的独立路径条数，这是确保程序中每个可执行语句至少执行一次所必需的测试用例数目的上界。 基本(独立)路径：指程序的控制流图中从入口到出口的路径，该路径包括一组以前没有处理的语句或条件。 基本路径集不是唯一的，对于给定的控制流图，可以得到不同的基本路径集。

步骤4：设计测试用例 根据前面所得到的基本路径集，设计测试用例，覆盖全部基本路径。 只要设计出的测试用例能够确保这些基本路径的执行，就可以使得程序中的每个可执行语句至少执行一次，每个条件的取真和取假分支也能得到测试。

(3) 控制结构测试 基本路径测试技术是控制结构测试技术之一。尽管基本路径测试简单高效，但是其并不充分。 控制结构测试中的其它测试技术：

3. 黑盒测试技术 (1) 等价类划分 **这一方法完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。**黑盒测试中，用所有可以输入的数据来测试程序是不可能的，只可能从全部可供输入的数据中选择一个子集进行测试。因此，该方法是把所有可能的输入数据划分为若干部分，从每一部分中选取少数有代表性的数据作为测试用例。

**划分等价类：**所谓等价类是指某个输入域的子集合，在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。

等价类的划分有两种不同的情况：

划分等价类的原则： 按区间划分 按数值集合划分 输入条件是一个布尔量的划分 按数值划分 按限制条件或规则划分 如果已划分的等价类中各元素在程序中的处理方式不同，则应将此等价类进一步划分成更小的等价类

(2) 边界值分析 人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。

这里所说的边界是指，相当于输入等价类和输出等价类而言，稍高于其边界值及稍低于其边界值的一些特定情况。

边界值分析方法是最有效的黑盒测试方法，但当边界情况很复杂的时候，要找出适当的测试用例还需针对问题的输入域、输出域边界，耐心细致地逐个考虑。

边界值分析法选取测试用例的原则：

(3)错误推测法 错误推测法指的是人们依靠经验和直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的例子的测试方法。 错误推测法的基本想法是：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。

(4)因果图 如果在测试时必须考虑输入条件的各种组合，可能的组合数将是天文数字。因此必须考虑使用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例，这就需要利用因果图。 因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。

4. 测试方法选择的综合策略 在任何情况下都必须使用边界值分析方法。经验表明用这种方法设计出测试用例发现程序错误的能力最强 必要时用等价类划分方法补充一些测试用例 用错误推测法再追加一些测试用例 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当再补充足够的测试用例 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法

软件测试过程包括单元测试、集成测试、确认测试、系统测试和验收测试 1. 单元测试 单元测试又称为模块测试，是针对程序模块进行正确性检验的测试。主要采用白盒测试为主、黑盒测试为辅的测试方法

单元测试的内容

单元测试的步骤 单元测试在编码阶段进行，是编码步骤的附属部分。源程序代码编制完成，经过评审和验证，确认没有语法错误之后，就开始进行单元测试的测试用例设计

模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相联系的其它模块。

这些辅助模块分为两种： 驱动模块（driver）：相当于被测模块的主程序。它接收测试数据，把这些数据传送给被测模块，最后输出实测结果。 桩模块（stub）：也叫做存根模块，用以代替被测模块调用的子模块。

2. 集成测试 在单元测试的基础上，需要将所有模块按照设计要求组装成为系统。

把模块组装成为系统的方式有两种：

增量式集成方式的几种类型：

3. 确认测试 确认测试又称有效性测试，它的任务是验证软件的有效性，即验证软件的功能和性能及其它特性是否与用户的要求一致。 确认测试步骤：首先进行有效性测试，其次进行软件配置复审，在通过了专家鉴定之后，才能成为可交付的软件。

有效性测试（功能测试） 有效性测试是在模拟的环境（可能就是开发的环境）下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求

软件配置复查： 软件配置复查的目的是保证软件配置的所有成分都齐全，各方面的质量都符合要求，具有维护阶段所必需的细节，而且已经编排好分类的目录

4. 系统测试 所谓系统测试，是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行（使用）环境下，对计算机系统进行一系列的组装测试和确认测试。

系统测试包括：

5. 验收测试 系统试运行一段时间后，各方面均已满足需求，可以进行验收，验收前展开的最后测试叫做验收测试。

1. 软件维护的定义 所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程，即在软件运行∕维护阶段对软件产品所进行的一切改动。

进行软件维护的原因：

2. 软件维护的分类

软件工程基础知识点总结 第20篇

模块化是按规定的原则将一个大型软件划分为一个个较小的、相对独立但又相关的模块。

模块设计的准则：

（1） 改进软件结构， 提高模块独立性：在对初步模块进行合并、分解和移动的分析、精化过程中力求提高模块的内聚，降低藕合。

(2） 模块大小要适中：大约50行语句的代码,过大的模块应分解以提高理解性和可维护性；过小的模块，合并到上级模块中。

（3) 软件结构图的深度、宽度、扇入和扇出要适当。一般模块的调用个数不要超过5个。

(4） 尽量降低模块接口的复杂程度；

（5） 设计单入口、单出口的模块。

（6) 模块的作用域应在控制域之内。

软件工程基础知识点总结 第21篇

黑盒测试：也称为功能测试,它着眼于程序的外部特征，而不考虑程序的内部逻辑结构。测试者把被测程序看成一个黑盒，不用关心程序的内部结构。黑盒测试是在程序接口处进行测试，它只检查程序功能是否能按照规格说明书的规定正常使用，程序是否能适当地接收输入数据产生正确的输出信息，并且保持外部信息（如数据库或文件)的完整性。

黑盒测试主要采用的技术有:等价分类法、边沿值分析法、错误推测法和因果图等技术。

软件工程基础知识点总结 第22篇

分层的目的：便于逐步细化、结构清晰。

画分层的DFD要遵循哪些原则:

（1)父图与子图之间数据要平衡。

(2)分解的深度和层次达到使加工足够简单、易于理解的基本加工为止。

（3）区分局部文件和局部外部项(局限于数据流中某一层或某几层的文件和外部项）.

(4）不要把控制流作为数据流.

（5）忽略琐碎的枝节。

（6)每个数据流要有一个合适的名字，尽量使用现实系统中有具体意义的名字。

软件工程基础知识点总结 第23篇

（1）  名字说明:程序中使用对象的名字，能为编译程序所检查和识别；

（2）  类型说明：定义对象的类型,确定该对象的使用方式；

（3)  初始化:为变量提供适当的初始值或由系统给变量赋一特殊的表明未初始化的值;

(4)  对象的局部性：程序中真正需要的那部分才能访问的对象;

(5）  程序模块:控制程序对象的名字；

(6）  循环控制结构:如FOR语句、WHILE—DO语句、REPEAT—UNTIL语句等;

（7）  分支控制结构:如IF语句、CASE语句等；

(8）  异常处理:为程序运行过程中发生的错误和意外事件提供检测和处理上的帮助;

(9）  独立编译：能分别编译各个程序单元.

软件工程基础知识点总结 第24篇

可行性分析的结果是可行性研究报告，内容包括：

（1) 系统概述:说明开发的系统名称，提出单位和开发单位。

(2） 可行性研究的前提：系统目标；要求;约束和限制;可行性研究的基本准则等。

（3） 对现有系统的分析：处理流程，图示说明现有系统的处理流程和数据流程；现有系统存在的问题。

（4） 系统需求：主要功能;主要性能及其要求；操作要求;信息要求；限制性要求。

（5) 建议系统：系统目标；处理流程;系统结构，功能，性能;系统技术可行性；投资和效益分析;操作可行性；法律可行性.

（6） 其它可选方案：与国内外同类型方案的比较;提出一两个可行性方案供论证和探讨。

(7） 制定下一阶段的预算。

（8) 结论性意见：由用户方、设计方和投资方共同签署意见.

第三章需求分析

软件工程基础知识点总结 第25篇

（1） 充分吸收和借鉴人类长期以来从事各种工程项目中积累的行之有效的有效原理、概念、技术与方法，特别是吸取几十年来人类从事计算机硬件研究和开发的经验教训。在开发软件的过程中努力作到良好的组织,严格的管理，相互友好的协作。

（2） 推广在实践中总结出来的开发软件的成功的技术和方法，并研究更好、更有效的技术和方法，尽快克服在计算机系统早期发展阶段形成的一些错误概念和作法。

（3） 根据不同的应用领域,开发更好的软件工具并使用这些工具。将软件开发各个阶段使用的软件工具集合成一个整体,形成一个很好的软件开发支环环境。

总之为了解决软件危机，既要有技术措施(方法和工具），又要有必要的组织管理措施.

软件工程基础知识点总结 第26篇

1. 系统分析 系统分析是一组统称为计算机系统工程的活动。它着眼于所有的系统元素，而不仅仅是软件。 系统分析主要探索软件项目的目标、市场预期、主要的技术指标等，用于帮助决策者做出是否进行软件项目立项的决定。

2. 可行性分析（Feasibility-study） 可行性分析的目的不是解决问题，而是确定问题是否值得去解决。 针对项目的目标和范围进行概要的分析和研究，探索问题域中的核心问题及其相应的解决方案，进一步为决策者提供经济、技术甚至是法律上可行性的分析报告。

1. 需求的定义 宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么 通俗的软件需求定义：针对待开发的软件产品，软件开发人员通过对软件产品的拥有者和使用者的交流和调研，获取相关的业务职能、业务知识和业务流程等信息，并对这些信息进行分析和整理后形成的有关该软件产品必须提供的功能和性能等指标的规格描述。

2. 需求的不确定性 需求的不确定性反映了需求的重要作用，需求分析的优劣对软件产品的质量影响最大。

软件需求分析的任务是：准确地定义新系统的目标，回答系统必须“做什么”的问题，并编制需求规格说明书。

需求分析的目标： 就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的 “做什么” 的问题。

分析建模的操作性原则：

需求分析的工程化原则：

软件的需求分析是一系列复杂的软件工程活动，为了便于对需求进行更好的管理，人们把所有与需求直接相关的活动通称为需求工程。 需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。

需求分析阶段的工作可以分成以下几个主要方面：

需求开发：

需求管理：

(1)需求获取的对象:用户和客户。 用户：使用软件的人员 客户：购买软件的人员 客户与最终用户可能是同一个人也可能不是同一个人 。

需求获取难点： 用户无法清楚地表达需求 需求分析员必须设法搞清楚用户真正的需求，这是需求分析员的职责。

需求的理解问题 需求分析员和用户都有可能误解需求，需求确认工作（属于需求管理）必不可少。 用户经常变更需求 需求变更并不可怕，可怕的是需求变更失去控制，导致项目混乱。

(2)需求获取流程

(3) 需求获取的准备工作 起草需求调查问题表，将调查重点锁定在该问题表内。（调查什么？ ） 确定需求调查的方式 。（如何调查？） 确定调查的时间、地点、人员等，撰写需求调查计划 。（“何人”在“何时”调查？ ）

需求调查的方式

(4) 需求获取与记录 在调查过程中随时记录（或存储）需求信息，建议采用表格的形式。

(5) 撰写用户需求说明书 需求分析员对收集到的所有需求信息进行分析，消除错误，归纳与总结共性的用户需求。然后按照指定的文档模板撰写《用户需求说明书》。

《用户需求说明书》不同于最终的《软件需求规格说明书》 前者主要采用自然语言来表达用户需求，其内容相对于后者而言比较粗略，不够详细。 后者是前者的细化，更多地采用计算机语言和图形符号来刻画需求，软件需求是软件系统设计的直接依据。 两者之间可能并不存在一一影射关系

(6) 软件需求类别 .功能需求 .性能需求 .环境需求 .可靠性需求 .安全保密要求 .用户界面需求 .资源使用需求 .软件成本消耗与开发进度需求 .预先估计以后系统可能达到的目标 除了上述需求之外，还需要考虑一些其他的非功能性的需求并进行相应的分析。

2. 软件需求定义

(1) 需求分析与综合 需求获取之后，对比较复杂的用户需求进行建模分析，帮助软件开发人员更好地理解需求。 在模型基础上，逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和设计上的限制，分析它们是否满足功能要求，是否合理。 依据功能需求，性能需求，运行环境需求等，剔除其不合理的部分，增加其需要部分。最终综合成系统的解决方案，给出目标系统的详细逻辑模型。

建模可以帮助软件开发人员更好地理解需求。 它着重于描述系统必须做什么、而不是如何去做系统。 该过程需要给出系统的逻辑视图（逻辑模型）以及系统的物理视图（物理模型）。

常用的建模分析方法

(3) 编制需求分析文档

好的《软件需求规格说明书》应具备如下属性： 正确、清楚、无二义性、一致、必要、完备、可实现、可验证、确定优先级、阐述“做什么”而不是“怎么做”。

需求分析评审的主要内容：

评判需求优劣的主要指标有： 正确性、清晰性、无二义性、一致性、必要性、完备性、可实现性、可验证性。

软件工程基础知识点总结 第27篇

·P (Plan) : 软件规格说明（Specification）。规定软件的功能及其使用的限制； ·D (Do) : 软件开发。产生满足规格说明的软件； ·C (Check) : 软件确认。通过有效性验证以保证软件能够满足客户的要求； ·A (Action) : 软件演进。为满足客户的变更要求，软件必须在使用的过程中不断地改进。

事实上，软件工程过程是一个软件开发机构针对某一类软件产品为自己规定的工作步骤，它应当是科学的、合理的，否则必将影响到软件产品的质量。

软件生命周期(software life cycle )是指软件产品从考虑其概念开始，到该软件产品不再使用为止的整个时期，一般包括概念阶段、分析与设计阶段、构造阶段、移交阶段等不同时期。

在整个软件生命周期中贯穿了软件工程过程的六个基本活动:

① 制定计划: 确定要开发软件系统的总目标，给出它的功能、性能、可靠性以及接口等方面的要求；研究完成该项软件任务的可行性，探讨解决问题的可能方案；制定完成开发任务的实施计划，连同可行性研究报告，提交管理部门审查。 ② 需求分析和定义:对待开发软件提出的需求进行分析并给出详细的定义。编写出软件需求说明书及初步的用户手册，提交管理机构评审。 ③ 软件设计:设计是软件工程的技术核心。把已确定了的各项需求转换成一个相应的体系结构。进而对每个模块要完成的工作进行具体的描述。编写设计说明书，提交评审。 ④ 程序编写:把软件设计转换成计算机可以接受的程序代码。 ⑤ 软件测试:在设计测试用例的基础上检验软件的各个组成部分。 ⑥ 运行／维护:已交付的软件投入正式使用，并在运行过程中进行适当的维护。

软件过程模型有时也称软件生命周期模型，即描述从软件需求定义直至软件经使用后废弃为止，跨越整个生存期的软件开发、运行和维护所实施的全部过程、活动和任务的结构框架，同时描述生命周期不同阶段产生的软件工件，明确活动的执行角色等。

九个传统软件生命周期模型： .瀑布模型 .螺旋模型 .V模型和W模型 .喷泉模型 .原型方法 .构件组装模型 .演化模型 .快速应用开发模型 .增量模型

优点： ⑴ 软件生命周期的阶段划分不仅降低了软件开发的复杂程度，而且提高了软件开发过程的透明性，便于将软件工程过程和软件管理过程有机地融合在一起，从而提高软件开发过程的可管理性。 ⑵ 推迟了软件实现，强调在软件实现前必须进行分析和设计工作。 ⑶ 瀑布模型以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导，保证了阶段之间的正确衔接，能够及时发现并纠正开发过程中存在的缺陷，从而能够使产品达到预期的质量要求。

缺点： ⑴ 模型缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题，这是瀑布模型最突出的缺点。因此，瀑布模型只适合于需求明确的软件项目。 ⑵ 模型的风险控制能力较弱。成品时间长；体系结构的风险和错误只有在测试阶段才能发现，返工导致项目延期。 ⑶软件活动是文档驱动的，文档过多会增加工作量，文档完成情况会误导管理人员。

(1) V模型——瀑布模型的变种

V模型仍然将测试作为一个独立的阶段，所以并没有提高模型抵抗风险的能力。

(2) W模型——瀑布模型的变种

W模型由两个V型模型组成，分别代表测试与开发过程 ，两个过程是同步进行的。

1. 提出原因 完整准确的需求规格说明很难得到 通过加强评审和确认、全面测试也不能从根本上解决需求不稳定带来的问题。

2. 概述 原型：是指模拟某种产品的原始模型。软件原型是一个早期可以运行的版本，它反映最终系统的部分重要特性。

原型方法构造软件系统 ：

原型化方法是在研究需求分析技术的过程中产生的，但也可以用于软件开发的其他阶段

3. 原型的种类（目的） 探索型：弄清对目标系统的要求 实验型：系统实现前考察系统的可行性 进化型：将原型扩展到开发过程，通过原型开发逐步实现所有系统功能。

4. 原型的使用策略 废弃策略：探索型和实验型 追加策略：进化型 原型不同于最终的系统，需要快速实现和运行，因此，原型可以忽略一切暂时不必关心的部分（抽象）

5. 优点

6. 缺点

7. 应用过程

8. 原型方法支持的软件生命周期 原型方法可以支持软件生命周期的不同阶段： 辅助或代替分析阶段 (确定需求) 辅助设计阶段 (确定设计方案的合理性) 代替分析与设计阶段 代替分析、设计和实现阶段 代替全部开发阶段 (典型的演化模型 )

项目开发初始阶段对需求的认识不够清晰，使得开发工作出现再开发在所难免。经验告诉我们：开发“两次”后的软件能较好地满足用户的要求。

演化模型主要针对需求不是很明确的软件项目

演化模型缺点：

结合了瀑布模型和演化模型的优点。

1. 增量模型优点

2. 增量模型缺点

针对大型软件项目的特点提出。

螺旋模型沿着螺线旋转，在四个象限上分别表达了四个方面的活动，即：

螺旋模型适合于大型软件的开发;然而风险分析需要相当丰富的评估经验，风险的规避又需要深厚的专业知识，这给螺旋模型的应用增加了难度。

喷泉模型认为软件开发过程具有两个固有的本质特征： 迭代：多次重复、演进。 无间隙：各阶段间无明显的界限。支持分析和设计结果的自然复用。

适用：面向对象的软件开发过程。对象概念的引入，对象及对象关系在分析、设计和实现阶段的表达方式的统一，使得开发活动之间的迭代和无间隙性能够容易地实现。

构件组装模型本质上是演化的，开发过程是迭代的。 构建组装模型由五个阶段组成： 需求定义和分析 软件体系结构设计 构件开发 应用软件构造 测试和发布

软件的开发过程步骤如下： (1)定义和分析需求； (2)标识本项目需要什么构件； (3)从库中查找构件或相似的构件； (4)如果可用转(5)，否则自行开发或修改，确认后入库； (5)构造为新系统作第m次迭代； (6)测试、确认。

快速应用开发(Rapid Application Development，RAD)是一个增量型的软件开发过程模型，采用构件组装方法进行快速开发。

RAD模型包含如下阶段： (1)业务建模：通过捕获业务过程中信息流的流动及处理情况描述业务处理系统应该完成的功能。回答以什么信息驱动业务过程运作? 要生成什么信息? 谁生成它? 信息流的去向? 由谁处理? 可以辅之以数据流图。 (2)数据建模：对于支持业务过程的数据流，建立数据对象集合,定义数据对象属性,与其它数据对象的关系构成数据模型，可辅之以E-R图。 (3)过程建模：定义如何使数据对象在信息流中完成各业务功能。描述数据对象的增加、修改、删除、查找。即细化数据流图中的处理框。 (4)应用生成：利用第四代语言(4GL)写出处理程序，重用已有构件或创建新的可重用构件，利用环境提供的工具，自动生成，构造出整个的应用系统。 (5)测试及迭代：由于大量重用，一般只作总体测试，但新创建的构件还是要测试的。当一轮需求完成快速开发后，可以迭代进入下一轮需求的开发。

RUP（Rational Unified Process）是一个面向对象的基于web的程序开发方法论。 RUP既是一种软件生命周期模型，又是一种支持面向对象软件开发的工具，它将软件开发过程要素和软件工件要素整合在统一的框架中。

(1) RUP的基本结构 RUP是一个二维的软件开发模型。 横轴在时间上将生命周期过程展开成四个阶段（Phase），每个阶段特有的里程碑（Milestone）是该阶段结束的标志，每个阶段里又划分为不同的迭代（Iteration），体现了软件开发过程的动态结构。

纵轴按照活动的内容进行组织，包括活动（activity）、活动产出的工件（artifact）、活动的执行角色（worker）以及活动执行的工作流（workflow），体现软件开发过程的静态结构。

1 - 初始阶段

阶段目标：通过业务用例（Business Use Case）了解业务并确定项目的边界，包括项目的验收规范、风险评估、所需资源估计、阶段计划等。

要确定项目边界，需识别所有与系统交互的外部实体，主要包括识别外部角色（actor）、识别所有用例并详细描述一些重要的用例。

Milestone：软件目标里程碑。包括一些重要的文档，如项目愿景（vision）、原始用例模型、原始业务风险评估、一个或者多个原型、原始业务场景等。

需要对这些文档进行评审，以确定正确理解用例需求、项目风险评估合理、阶段计划可行等。

2 - 细化阶段

阶段目标：分析问题领域，建立适合需求的软件体系结构基础，编制项目计划，完成项目中技术要求高、风险大的关键需求的开发。

Milestone：体系结构里程碑。包括风险分析文档、软件体系结构基线(baseline)、项目计划、可执行的进化原型、初始版本的用户手册等。

通过评审确定软件体系结构的稳定性、确认高风险的业务需求和技术机制已经解决、修订的项目计划可行等。

3 - 构造阶段

阶段目标：将所有剩余的技术构件和稳定业务需求功能开发出来，并集成为产品，所有功能被详细测试。从某种意义上说，构造阶段只是一个制造过程，其重点放在管理资源及控制开发过程以优化成本、进度和质量。

Milestone：运行能力里程碑。包括可以运行的软件产品、用户手册等，它决定了产品是否可以在测试环境中进行部署。

要确定软件、环境、用户是否可以开始系统的运行。

4 - 移交阶段

阶段目标：软件产品正常运行并交付用户使用。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量调整。

Milestone：产品发布里程碑。包括维护和售后支持文档手册等。

要确定最终目标是否实现，是否应该开始产品下一个版本的另一个开发周期。

(2) RUP的迭代增量开发思想 RUP是以用例为驱动，软件体系结构为核心，应用迭代及增量的新型软件生命周期模型

RUP的每一个阶段可以进一步划分为一个或多个迭代过程，从一个迭代过程到另一个迭代过程增量形成最终的系统。 RUP是融合了喷泉模型和增量模型的一种综合生命周期模型 。

RUP将整个项目的开发目标划分成一些更易于完成和达到的阶段性小目标。每一次迭代就是为了完成一定阶段性小目标而从事的一系列开发活动，包含需求、设计、实施（编码）、部署、测试等。

(3) RUP的核心工作流 6个核心过程工作流(Core Process Workflows)

3个核心支持工作流(Core Supporting Workflows)

(4) RUP的最佳实践Best Practice

(1) 定义 敏捷方法的主要特点就是具有快速及灵活的响应变更的能力

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

敏捷方法很多,包括xxx程(XP)、 Scrum、功能驱动开发(FDD)、水晶、净室开发等多种方法，这些方法本质实际上是一样的，都遵循“敏捷宣言”原则。

(2) xxx程 (eXtreme Programming )

XP是一种轻量级的软件开发方法，是一种以实践为基础的软件工程过程和思想。 它使用快速的反馈，大量而迅速的交流，经过保证的测试来最大限度的满足用户的需求。 XP强调用户满意，开发人员可以对需求的变化作出快速的反应。

XP的工作环境 每个参加项目开发的人都将担任一个角色（项目经理、项目监督人等等）并履行相应的权利和义务。 用户也是项目组的一部分。 所有人都在同一个开放的开发环境中工作。

XP的需求分析

XP的设计 从开发的角度来看，XP内层的过程是一个基于Test Driven Development周期，每个开发周期都有很多相应的单元测试。 随着这些测试的进行，通过的单元测试也越来越多。通过这种方式，客户和开发人员都很容易检验，是否履行了对客户的承诺。

同时，XP还大力提倡设计复核（Review）、代码复核以及重整和优化（Refectory），所有的这些过程其实也是优化设计的过程；

XP的编程 XP提倡配对编程（Pair Programming），而且代码所有权是归于整个开发队伍（Collective Code Ownership）。 程序员在写程序和重整优化程序的时候，都要严格遵守编程规范。 任何人都可以修改其他人写的程序，修改后要确定新程序能通过单元测试。

XP的测试 XP提倡在开始写程序之前先写单元测试。

软件工程基础知识点总结 第28篇

非渐增式测试方式：分别测试模块，再把所有模块按设计要求放在一起组成所要的程序。该方法编写测试软件工作量大，模块间的接口错误发现得晚,错误定位较难诊断,总体测试有的错误容易漏掉，测试时间相对较少，可以并行测试所有模块,能充分利用人力,加快工程进度。。

渐增式测试方式：把下一个要测试的模块，同已经测试好的那些模块结合起来进行测试。该方法利用已测试过的模块作测试软件，开销小,较早发现模块间的接口错误,错误定位往往和最近入的模块相关，对已测试好的模块可在新加入模块的条件下受到新的检验，测试更彻底，需要较多的测试时间,不能并行测试。

总的来说，渐增式测试方法比较好。

软件工程基础知识点总结 第29篇

提纲 分析模型的结构 软件需求规格说明书

Structured Analysis（SA）：面向数据流进行需求分析，适合于数据处理类型软件的需求分析。

为了把用户的数据要求清晰明确地表达出来，软件开发人员通常建立一个概念性的数据模型（也称为信息模型）。

概念性模型是一种面向问题的数据模型，是按照用户的观点来对数据和信息建模。它描述了从用户角度看到的数据，反映了用户的现实环境，但与在软件系统中的实现方法无关。

最常用的表示概念性数据模型的方法，是实体/关系方法（Entity Relationship Approach）。这种方法用ER图描述现实世界中的实体，而不涉及这些实体在系统中的实现方法。用这种方法表示的概念性数据模型又称为ER模型。

数据对象(实体)、属性和关系

ER图的主要目的是以图形的形式表示实体以及实体之间的关系。 ER图标识了一组基本的构件：实体、属性、关系。

带标记（或名称）的矩形表示实体，连接实体的线表示关系。

规范化的目的是消除数据冗余，即消除实体表中数据的重复。 消除多义性，使关系中的属性含义清楚、单一； 使关系单纯化，让每个数据项只是简单的数或字符串，方便操作。 使数据的插入、删除与修改操作可行且方便； 使关系模式更灵活，易于实现接近自然语言的查询方式。

关系规范化的程度通常按属性间的依赖程度来区分，并以范式（Normal Form，NF）来表达。范式是符合某一种级别的关系模式的集合。

目前关系数据库有六种范式。一般说来，数据库只需满足**第三范式（3NF）**就可以达到设计的要求了。