软件工程 (2) 软件工程学科概念 (1) 软件工程相关知识点 (1) 传统软件工程 (1)

传统软件工程学科中的概念、相关知识点总结

1、软件与软件工程

1.1 软件的概念、软件的特点、软件发展的四个阶段

软件的概念

• 软件是计算机系统的重要组成部分；
• 软件是逻辑产品，需要计算机硬件和系统软件的支撑；
• 软件是计算机控制系统的指挥中枢；
• 软件是信息转换器，它能对信息进行加工、处理或变换；
• 软件是工具，在人们的生活、工作、休闲，在社会的经济、军事、政治、文化、科学技术、教育中发挥具大作用

软件是能够完成预定功能和性能，并对相应数据进行加工的程序和描述程序及其操作的文档。
软件 = 程序+数据+文档
程序 = 算法+数据结构

软件的特点

• 软件是被开发或设计的,而不是传统意义上被制造的
• 软件不会”磨损”
• 软件产业逐步走向基于构件的组装,但还是定制的

软件发展的四个阶段

• 1950—1965,没有系统的软件开发方法和管理机制、自定义软件、批处理、有限分布。
• 1965—1975,产生人机交互的新概念、新技术软件产品、多用户、实时、数据库。
• 1973—1988,微处理器的出现并广泛应用,分布式系统、嵌入智能、低成本硬件、消费者的影响。
• 1986—2000,广域和局域网络迅速普及,强大的桌面系统、面向对象技术、专家系统、人工智能、神经网络、并行计算、网络计算机。

1.2 软件危机产生的原因，解决软件危机的方法

软件危机产生的原因

• 软件的规模加大、复杂性提高、性能增强
• 软件是逻辑产品, 尚未完全认识其本质和特点
• 缺乏有效的、系统的开发、维护大型软件项目的技术手段和管理方法
• 用户对软件需求的描述和软件开发人员对需求的理解往往存在差异，用户经常要求修改需求，开发人员很难适应
• 软件开发的技术人员和管理人员缺乏软件工程化的素质和要求，对工程化的开销认识不足

解决软件危机的办法

1.3 软件工程的概念，软件工程的三要素

软件工程的概念

• 软件工程 Fritz Bauer[nau69]：为了经济的获得可靠的，在实际机器上高效运行的软件，而建立和使用的好的工程原则。
• 软件工程 [ 教材]：软件工程是运用工程、科学和数学的原则与方法研制、维护计算机软件的有关技术和管理的方法。
• 软件工程[IEEE93]：将系统的、规范的、可度量的方法应用于软件的开发、运行和维护的过程。

软件工程的三要素

过程、工具、方法

1.4 软件生命周期个阶段及其基本任务

• 软件定义
  • 问题定义：确定系统的总体目标
  • 可行性分析：研究经济、技术、操作等的可信性
  • 需求分析：收集需求，需求建模
• 软件开发
  • 系统设计：软件结构设计、数据设计、接口设计和过程设计
  • 编码：产生源程序清单
  • 测试： 产生软件测试计划和软件测试报告
• 软件运行
  • 维护：修改、完善、扩展软件

1.5 软件开发过程模型：瀑布模型、原型模型、螺旋模型等几种模型的形式与特点及使用范围

瀑布模型

• 主要思想：

软件开发过程与软件生命周期是一致的
相邻二阶段之间存在因果关系
需对阶段性产品进行评审

• 示意图：

• 瀑布模型的优点：
  软件生命周期模型，使软件开发过程可以再分心、设计、编码、测试和维护的框架下进行
  软件开发过程具有系统性、可控性，客服了软件开发的随意性

• 瀑布模型的缺点：
  项目开始阶段很难精确提出产品需求，由于技术进步，用户对系统深入的理解，修改需求十分普遍
  项目开发晚期才能的带程序的运行版本，这是修稿软件需求和开发中的错误代价很大
  采用线性模型组织项目开发经常发生开发小组人员“堵塞状态”，特别是项目的开始和结束

原型模型

• 原型模型示意图

• 优点：
  原型模型支持软件需求开发，帮助用户和开发人员理解需求，使软件需求工程的关键
  它产生的正式需求文档，是软件开发的基础
  如果开发的原型是可运行的，它的若干高质量的程序片段和开发工具可用于工作程序的开发
  原型的开发和评审时系统分析员和用户/客户共同参与的迭代过程，每个迭代循环都是线性过程

• 缺点：
  对于大型软件项目，RAD模型需要足够的人力资源已建立足够的原型组
  RAD模型要求开发者和客户再一段时间内共同完成原型系统的开发，如果任何一方没有实现承诺，会导致原型开发的失败
  如果系统难以模块化，建造RAD模型所需构建就有问题，如果高性能是一个指标，RAD模型也可能不奏效
  RAD模型不适合采用很多新技术的项目

• RAD模型的开发过程：
  业务建模-> 数据建模->过程建模->应用生成->测试修正

螺旋模型

• 螺旋模型=线性模型+迭代，原型+系统化
  螺旋模型适用于计算机软件整个生命周期

• 示意图

• 示意图

• 优点：
  符合人们认识现实世界和软件开发的客覌规律；
  支持软件整个生命周期；
  保持瀑布模型的系统性、阶段性；
  利用原型评估降低开发风险；
  开发者和用户共同参与软件开发，尽早发现软件中的错误；
  不断推出和完善软件版本，有助于需求变化，获取用户需求，加强对需求的理解。

增量模型

• 小而可用的软件

• 特点：
  在前面增量的基础上开发后面的增量
  每个增量的开发可用瀑布或快速原型模型
  迭代的思路

并发开发模型

• 示意图：

形式化开发方法

• 用严格的、数学的符号体系来规约、开发和验证基于计算机的系统。 解决软件开发过程使用其它范型难以克服的二义性、不完整性和不一致性。 可以产生无缺陷软件的承诺。 费时、昂贵、难沟通，需要培训 是建造重要的、安全的软件的开发者可以考虑开发范型。比如：航空电子、医疗设备软件的开发。

2 软件项目管理

2.1软件项目管理的基本概念

软件项目管理

• 人员管理
  • 项目参与者
  • 项目负责人呢
  • 软件项目组
  • 协调通信问题
• 产品管理
  • 软件范围
  • 问题分解
• 过程管理
  • 确定软件过程模型
  • 过程分解
• 项目管理
  • 确定危险信息
  • 确定解决方案

2.2 软件项目估算（代码行、功能点估算）

2.2.1 度量 metrics

度量具有数字特征，软件工程范围的度量是软件开发过程、软件资源或软件产品简单属性的定量描述。
如，程序规模、操作符个数、程序中错误的个数等

2.2.2 估算 estimation

对软件产品、过程、资源进行预测
估算可以采用经验公式、或参考历史资料
估算用于事前签订合同、立项、制定工作计划等

2.2.3 面向规模的度量

• 代码行数 LOC或 KLOC
• 生产率 p1 = L/E，其中，L软件项目代码行数，E软件项目工作量，P1软件项目生产率（LOC/PM）
• 代码出错率： EQR1 = Ne/L，其中，Ne软件项目的代码错误数，EQR1每千行代码的错误数。
• 每行代码的平均成本，CI=S/L，其中S为软件项目总开销，CI为软件项目每行代码的平均成本。
• 文档与代码比，DI=Pd/L，其中，Pd软件项目文档页数，DI每千行代码的平均文档数。
• M 为人数，PM 为工作量

2.2.3.1 规模度量的优缺点

• 优点：
  • 用软件代码行数估算软件规模简单易行。
• 缺点：
  • 代码行数的估算依赖于程序设计语言的功能和表达能力
  • 采用代码行估算方法会对设计精巧的软件项目产生不利的影响
  • 在软件项目开发前或开发初期估算它的代码行数十分困难
  • 代码行估算只适用于过程式程序设计语言，对非过程式的程序设计语言不太适用等等。

2.2.4 面向功能的度量

2.2.4.1 根据事务信息处理程序的基本功能定义的，在系统设计初期可以估算出软件项目的规模：
FP=CT* ［0.65+0.01*∑Fi ］ 其中：CT 按表3.1 计算()，Fi 是复杂性调节值，Fi值取值 0,1,…,5，当Fi = 0时，表示 Fi 不起作用，Fi = 5时，表示 Fi 作用最大。

一些符号代表的意思：

• 用户输入数，用户为软件提供的输入参数的个数
• 用户输出数，软件系统为用户提供的输出参数个数
• 用户查询数，哟个练级输入确定一次查询，软件以联机输出的形式，实时的产生一个响应。
• 文件数，统计逻辑的主文件个数
• 外部界面数，统计所有机器可读的界面，利用这些界面可以将信息从一个系统传送到另一个系统。

计算方法：　　

• 生产率： Pf=FP/E，其中，Pf表示每人月完成的功能点数。
• 平均成本：Ci=S/FP，其中，Ci表示每功能点的平均成本。
• 文档用与功能点比：Di=Pd/FP，其中，Di表示每个功能点平均具有的文档页数。
• 代码出错率： EORi = Ne/FP，其中，EORi表示每个功能点的平均错误个数。

简单功能点与功能点：

• FPs，简单功能点。
• FP，功能点，引入了算法复杂性因素。

优缺点：

• 优点：
  • 与程序设计语言无关 ， 它不仅适用于过程式语言 ， 也适用于非过程式的语言。
  • 软件项目开发初期就能基本上确定系统的输入 、输出等参数 ， 功能点度量能用于软件项目的开发初期
• 缺点：
  • 它涉及到的主观因素比较多 ， 如各种权函数的取值
  • 信息领域中的某些数据有时不容易采集
  • FP 的值没有直观的物理意义

2.2.5 代码行度量与功能点度量的比较

• 代码行度量依赖于程序设计语言， 而功能点度量不依赖于程序设计语言
• Albrecht 和Jones 等人对若干软件采用事后处理的方式分别统计出不同程序设计语言每个功能点与代码行数的关系 ，用 用LOC/FP 的平均值表示。
• ，行 一行Ada 语言代码的 “ 功能 ” 平均行是一行FORTRAN 语言代码 “ 功能 ”的1.4倍，一行四代语言代码的 “ 功能 ” 平均是一行传统程序设计语言代码 “ 功能 ”的3至5倍

2.2.6 各种语言的LOC/FP（平均值）

汇编语言 300， COBOL 100， FORTRAN 100， Pascal 90， Ada 70， 面向对象的语言 30， 四代语言(4GL) 20， 代码生成器 15，

2.3 McCabe度量法，能完成环路复杂度的度量

2.3.1 定义

McCabe 度量法又称环路复杂性度量，基于程序控制结构的软件复杂性度量模型。

2.3.2 程序控制结构图

• 程序结构对应于有一个入口结点和一个出口结点的有向图
• 途中每个结点对应一个语句或一个顺序流程的程序代码块
• 弧对应于程序中的转移
• 它基于一个程序模块的程序图中环路的个数，因此计算它先要画出程序图。
• 程序图是退化的程序流程图，流程图中每个处理都退化成一个结点，流线变成链接不同结点的有向弧。

2.3.3 McCabe 度量法

McCabe 用程序控制结构图的巡回秩数V（G）作为程序结构复杂性的度量
V(G) = e-n+2
其中，e为结构图的边数，n为结构图的结点数
可以证明V(G) 等于结构图中有界或无界的封闭区域个数。

V(G)的值不要大于10，当V(G)>10时，模块内部结构就会变得复杂，给编码和测试带来困难。

2.3.4 McCabe 度量的缺点

• 对于不同种类的控制流的复杂性不能区分
• 简单IF语句与循环语句的复杂性同等看待
• 嵌套IF语句与简单CASE语句的复杂性是一样的
• 木块间借口当成一个简单分支一样处理
• 一个具有1000行的顺序程序与一行语句的复杂性相同

2.4 成本估算方法及其特点

估算可以采用经验公式、或参考历史资料
估算用于事前签订合同、立项、制定工作计划等

常用的估算方法：

• 参照已经完成的类似项目估算待开发项目的成本和工作量。
• 将大的项目分解为若干个子项目，在估算出每个子项目成本和工作量之后，再估算整个项目。
• 将软件项目按软件生存周期分解，分别估算出软件项目在软件开发各个阶段的工作量和成本，然后再把这些工作量和成本汇总估算整个项目。
• 根据试验或历史数据给出软件项目工作量或成本的经验估算公式。

四种方法可以同时、单独或组合使用，以便取长补短，提高项目估算的精度和可靠性。采用分解技术辐射那软件项目应考虑系统集成是需要的工作量。为了实现呢软件项目估算，实践中开发了大量的软件项目自动估算工具，用以支持软件工作量或成本估算。

2.4.1 分解技术

采用“分而治之”的策略就行软件项目估算。将项目分解为若干个主要的功能及相关的软件工程活动，通过逐步求精的方式进行成本及工作量估算。

2.4.3 经验估算模型

可用于补充分解技术

2.4.3.1 CoCoMo模型

• 计算机软件的估算模型是根据以前完成项目的实际数据导出的，用于软件项目的计划阶段。
• 模型是根据“从前的”，“局部的”数据得出的，估算模型不可能完全适用于当前所有软件项目和全部开发环境。这些模型的计算结果仅供参考。
• 两个常用的估算模型有：
  • CoCoMo模型（构造性成本模型）：1.实在静态、单变量模型的基础上构造出来的。2.分为基本、中间、详细三个层次，分别用于软件开发的三个不同阶段。3.基本CoCoMo模型，永固系统开发的初期，估算整个系统的工作量（包括软件维护）和软件开发所需要的时间。4.中间的CoCoMo模型，用于估算各个子系统的工作量和开发时间。5.详细的CoCoMo模型，用于估算独立的软部件，如子系统内部的各个模块。第三章，48页。
  • 经验估算模型，Putnam模型。1.是一个动态多变量模型，适用于软件开发的各个阶段，估算模型以大型软件项目的实测数据为基础，导出工作量分布曲线。2.它描述了开发工作量，开发时间和软件代码行数之间的关系。3.方程：第三章，61页。4.CK=2000：比较差的软件开发环境，8000一般的软件开发环境，11000比较好的软件开发环境。

2.4.4 自动估算工具

实现一种或多种分解技术或经验魔性，与人机交互结合，自动估算将是很好的选择。

2.5 关键路径法

2.6 CMM与CMMI的基本概念

2.6.1 CMM/能力成熟模型

对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。 CMM是一种用于评价软件承包能力以改善软件质量的方法，侧重于软件开发过程的管理及工程能力的提高与评估。分为五个等级：一级为初始级，二级为可重复级，三级为已定义级，四级为已管理级，五级为优化级。

2.6.2 CMMI/能力成熟度模型集成

其目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。

3 需求分析

3.1 软件需求内同

用户对目标软件系统在功能、行为、性能、设计、约束等方面的期望。
需求分析阶段的任务，通过对问题及环境的理解、分析，将用户需求精确化，完全化，最终形成需求规格说明，描述系统信息、功能和行为。

3.1.1 用户需求

用自然语言和图标描述，说明系统必须提供哪些服务、系统运行要受哪些约束

3.1.2 系统需求

详细说明系统将要提供的服务以及系统受到的约束，精确的描述软件的功能，系统买方和软件开发者签订合同的重要性。

3.1.3 软件设计描述

在系统需求的基础上，加入更详细的内容，构成软件设计活动的概要描述，是软件设计和实现的基础。

3.1.4 需求分析的三个阶段

问题分析，需求描述，需求评审

3.2 需求分析常用技术

3.2.1 初步需求获取技术

• 访谈与会议
  分析人员应精心准备问题，通过用户对问题的回答，逐步理解用户对目标软件的要求。（1）循序渐进，首先关心一般性，整体性问题，然后再谈论细节问题。（2）客观、公正，不应限制用户在回答问题过程中的自由发挥。（3）总结，问题汇总后应能反映软件或其子系统的全貌，能覆盖用户对目标软件或其子系统在功能、行为、性能诸方面的要求。
• 考察用户软件或其子系统业务流程 学习用户的有关业务知识，在用户帮助下了解用户的软件或子系统业务流程，结合软件开发和应用的经验提出新的用户需求。
• 联合小组 建立软件开发方和用户方共同组成的联合小组，小组成员对分析负有相同的责任。联合小组要制定自己的工作制度和计划，确定专门的记录员，另设专人负责会议的议程和资料的综合整理。选择易于理解、比较简介、精确的表示机制作为描述语言，如辅以文字说明的流程图。

3.2.2 需求建模技术

• 目标软件系统的模型用来刻画系统所涉及的信息、处理功能及系统运行时的外部行为。
• 模型不应设计软件实现细节
• 选择图形符号表示信息流、处理功能及系统行为，以此来描述软件需求模型。

3.2.3 快速原型技术

软件开发早期，快速建立目标软件系统原型 ，让用户对原型进行评估并提出意见 。 原型几经改进最终确定 ， 设计和编码人员遵循原型确立的外部特征实现软件产品 。如果软件产品含有大量人机交互 、 可视输出 、或者涉及复杂的算法 ， 应采用快速原型技术 。对于复杂问题, 可对某些子问题 ， 尤其是用户界面 ， 使用快速原型技术 。

3.2.4 问题抽象

抽象：关注一般问题的解决途径 ， 以此指导特殊问题的求解 。 注意用户描述的抽象级别 ， 统一规划系统 行为 。避免不一致性 ， 减少分析的工作量 。

3.2.5 问题分级与多视点分析

分解：根据问题的规模和复杂性进行分解 ， 并对子问题展开进一步的分析 。逐级分解 ， 直至子问题的规模降至合适程度 。在问题分解过程中 ， 要建立子问题之间的相互联系 。必须遵循子问题内部紧藕合 ， 子问题之间松藕合的原则

视点分解法：在分析的初期 ， 整体地把握一个大型问题的软件需求是困难的 。 需要从各个角度分别对问题进行理解和分析 ， 然后再综合 ， 达到全面理解的目

3.3 结构化分析方法

需求分析视点：系统观点，用户观点，信息观点功能观点，行为观点等 。整理 、 综合用户描述 ， 应注意用户视点的变化 ，避免遗漏

3.4 数据流图（DFD）的作用，能用数据流图完成需求分析，能废除精化数据流图，数据字典

第四章，第45页

4 软件设计基础

4.1 设计阶段主要任务

• 数据设计，把信息描述转换为实现软件所要求的数据结构 。
• 总体结构设计，旨在确定程序各主要部件之间的关系 。
• 过程设计，要完成每一部件的过程化描述 。
• 根据设计结果编制代码。然后交给测试人员测试
• 设计阶段做的决策直接影响软件质量, , 没有良好的设计就没有稳定的系统, , 也不会有易维护的软件 。
• 统计表明：设计、编码和测试这三个活动一般占用整个软件开发费用( ( 不包括维护阶段) ) 的 75% % 以上

4.2 软件设计准则（抽象、信息隐蔽、模块化、自顶向下逐步求精等）

• 抽象是管理、控制复杂性的基本策略。在最高抽象级别上,用面向问题域的语言叙述“问题”,概括 “ 问题解 ” 的形式。不断地具体化,不断地用 面向过程的语言描述问题。在最低的抽象级别上给出可直接实现的“问题解”，即程序
• “ 逐步求精 ” 的主要思想是针对某个功能的宏观描述用逐步求精的方法不断地分解,逐步确立过程细节,直至该功能用程序语言描述的算法实现为止
• 把软件划分为可独立命名和编址的部件，每个部件称为一个模块,当把所有模块组装到一起时则获得满足问题需要的一个解
• 信息隐藏
  • 模块应该设计得使其所含信息(过程和数据)对于那些不需要这些信息的模块不可访问
  • 每个模块只完成一个相对独立的特定功能
  • 模块之间仅仅交换那些为完成系统功能必须交换的信息，即模块应该独立
• 采用信息隐藏原理指导模块设计优点：
  • 支持模块的并行开发
  • 减少软件测试和软件维护的工作量

4.3 高内聚低耦合度的含义

内聚度：模块内部各成分彼此结合的紧密程度。
耦合度：软件结构中模块间关联程度的一种度量。

4.4 熟悉变换分析和事务分析，能用两种方法分析和构建软件程序结构图

4.4.1 变换分析

变换分析由一系列设计步骤组成，经过这些步骤就能把具有变换流特点的数据流图，按预先确定的模式映射成软件结构

1. 复审基本系统模型
2. 复审和精化软件数据流图
3. 确定ＤＦＤ为变换流还是事务流。
4. 划定输入流和输出流边界孤立变换中心
5. 执行“一级分解”导出具有三个层次的程序结构，一级分解的原则：在完成控制功能并保持低耦合度、高内聚度的前提下尽可能减少模块数
6. 执行 “ 二级分解 ”，把数据流图中每个处理框映射成程序结构中一个适当的模块，二级分解过程是从变换中心的边界开始沿输入、输出通道向外移动，把遇到的每个处理框映射为程序结构中的一个模块。
7. 采用启发式设计策略，精化所得程序结构雏形，改良软件质量。

4.4.2 事物分析

1. 复审基本系统模型
2. 复审并精华软件数据流图
3. 确定数据流图的特性，
4. 指出事物中心，确定由事物中心发出的每一动作路径的数据流图
5. 把数据流图映射为事务处理型的程序结构
6. 分解并精化事务结构以及每条动作路径所对应的结构
7. 使用启发式设计策略，精化所得程序结构雏形，改良软件质量

4.5 详细设计工具（程序流程图、盒图（N-S图）与PAD图之间的转化，能将伪码或程序转换成程序流程图、盒图（N-S图）与PAD图

8 软件测试

8.1 软件测试的目的和原则，软件测试流程

8.1.1 目的

• 软件测试是为了发现程序中的错误。
• 软件测试的过程亦是程序运行的过程。
• 程序运行需要数据, 为测试设计的数据称测试用例。
• 设计测试用例的原则自然是尽可能暴露错误。
• 软件测试是一个找错过程。
• 测试只能找出程序中的错误, 而不能证明程序无错

8.1.2 流程

8.2 软件测试计划

8.3 软件测试技术（白盒测试、黑盒测试、利用软件测试技术进行软件测试、设计测试用例）

8.3.1 导出测试用例：

• 以设计或源代码为基础，画出相应的流图。
• 确定所得流图的环的复杂性。
• 确定线性独立路径的基本合集。
• 准备测试用例，强制执行基本集合中的每条路径。

8.3.2 测试技术

• 基本路径测试
• 控制结构测试
  • 条件测试：通过检查程序汇总的包含的逻辑条件进行测试用例设计
  • 数据流测试：数据流测试方法就是根据标量的定义和使用位置来选择程序测试路径的测试方法
  • 分支和关系运算测试法BRO：能用少于2 n 次测试发现条件中大多数错误, 采用该方法的前提是条件中每个布尔变量和关系运算符至多出现一次并无公共变量
• 数据流测试：数据流测试方法就是根据标量的定义和使用位置来选择程序测试路径的测试方法
• 循环测试

8.3.3 黑盒测试：

• 等价分类法：等价分类法的主要思想是把程序的输入数据集合按输入条件划分为若干个等价类, 每一等价类相对于 输入条件表示为一组有效或无效的输入, 然后为每一等价类设计一个测试用例, 这样即可大大减小测试的次数又不丢失发现错误的机会
• 边界值分析法：BVA 技术是对等价分类技术的补充, 即在一个等价类中不是任选一个元素作为此等价类的代表进行测试, 而是选择此等价类边界上的值
• 比较测试：将软件工程的队伍以不同的版本划分，但是使用同一种规格每种版本都用相同的数据进行测试，以保证输 出是相同的，所有的版本都一同时间运行，使得到的结果具备一致性
• 正交数组测试：可以应用于输入域相对较小但对穷举测试而言又过大的问题
• 基于模型的测试： 分析软件的已有的行为模型或创建一个行为模型，遍历行为模型，并标明促使软件在状态之间进行转换的输入。评估行为模型，并标注当软件在状态之间转换时所期望的输出。运行测试用例。比较实际结果和期望结果，并根据需要进行调整。

8.4 软件测试策略（单元测试、集成测试、确认测试、验收测试、系统测试）的基本概念

8.4.1 单元测试

• 单元测试的对象是软件设计的最小单位 单元测试的对象是软件设计的最小单位——模块
• 单元测试的依据是详细设计描述，单元测试应对模块内所有重要的控制路径设计测试用例, 以便发现模块内部的错误
• 单元测试多采用白盒测试技术, 系统内多个模块可以并行地进行测试
• 任务：借口，局部数据结构，边界条件，错误处理路径

8.4.2 综合测试

综合测试是组装软件的系统测试技术, 按设计要求把通过单元测试的各个模块组装在一起之后, 进行综合测试以便发现与借口有关的各种错误。

8.4.3 自顶向下集成

• 自顶向下集成是构造程序结构的一种增量式方式,它从主控模块开始, 按照软件的控制层次结构, 以深度优先或广度优先的策略, 逐步把各个模块集成在一起。
• 优点：自顶向下集成的优点在于能尽早地对程序的主要控制和决策机制进行检验, 因此较早地发现错误
• 缺点：缺点是在测试较高层模块时, 低层处理采用桩模块替代, 不能反映真实情况, 重要数据不能及时回送到上层模块, 因此测试并不充分

8.4.4 自底向上集成

• 自底向上测试是从 “ 原子 ” 模块( 即软件结构最低层的模块)开始组装和测试, 因测试到较高层模块时, 所需的下层模块功能都已具备，所以不再需要桩模块。
• 优点：自底向上集成方法不用桩模块, 测试用例的设计亦相对简单,
• 缺点：程序最后一个模块加入时才具有整体形象

8.4.5 关键模块

8.4.6 综合测试文档

测试说明书应给出软件集成的总体规划和某特殊测试的描述。

关键模块应尽早测试

8.4.7 确认测试

确认测试应检查软件能否按合同要求进行工作, 即是否满足软件需求说明书中的确认标准。

10 软件维护

10.1 四种维护的类型，软件维护的概念、软件可维护性

10.1.1 四种维护

• 改正性维护
  在软件交付使用后，因开发时测试的 不彻底 、 不完全 ，必然会有部分隐藏的错误遗留到运行阶段。这些隐藏下来的错误在某些特定的使用环境下就会暴露出来。为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程就叫做改正性。
• 适应性维护
  在使用过程中，外部环境（新的硬、软件配置），数据环境（数据库、数据格式、数据输入、输出方式、数据存储介质）可能发生变化，卫视软件适应这种变化，而去修改软件的过程就叫做适应性维护。
• 完善性维护
  在软件的使用过程中，用户往往会对软件提出新的功能与性能的要求，为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。
• 预防性维护
  预防性维护是为了提高软件的可维护性、可靠性等，为以后的进一步改进软件打下良好基础。预防性维护定义为：采用现金的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试。

10.1.2 软件维护的概念

在软件运行。维护阶段软件产品进行的修改就是所谓的维护。

10.2 软件维护的技术有那几种

10.2.1 改正性维护

通过使用新技术，大大减少进行改正性维护的需要。这些技术包括：数据库管理系统、软件开发环境、程序自动生成系统、较高级（第四代）的语言，以及新的开发方法、软件复用、防错程序设计及周期性维护审查等。

10.2.2 适应性维护

这一类维护不可避免，可以控制。

• 在配置管理时，把硬件、操作系统和其他相关环境因素的可能变化考虑在内。
• 把与硬件、操作系统，以及其他外围设备有关的程序归到特定程序模块中
• 使用内部程序列表、外部文件，以及处理的例行程序包，可谓维护时修改程序提供方便。

10.2.3 完善性维护

利用前两类维护中列举的方法也可以减少这一类维护。特别是数据库管理系统、程序生成器、应用软件包，可减少维护工作量，此外，建立软件系统的原型，把它在实际系统开发之前提供给用户。用户通过研究原型，进一步完善他们的功能要求，就可以减少以后完善性维护的需要。

10.3 维护工作量的模型

M = p + Ke的c-d次方

M 是维护中消耗总工作量，p是上面描述的生产性工作量（如分析和评价、设计修改和实现），k是一个经验常数，c是因缺乏好的设计和文档而导致复杂性的度量，d是对软件熟悉程度的度量。

10.4 软件可维护性

软件可维护性的定义：

• 软件可维护性是指纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充或压缩的容易程度。
• 可维护性、可使用性、可靠性是衡量软件质量的主要质量特征。
• 软件的可维护性是软件开发阶段各个时期的关键目标。

10.4.1 衡量程序的可维护性

可理解性、可使用性、可测试性、可移植性、可修改性、效率、可靠性

• 可理解性
  表明人们通过阅读源代码和相关文档，了解程序功能机器如何运行的容易程度。

10.4.2 定量度量可维护性

• 质量检查表
  用于测试程序中某些质量特征是否存在的一个问题清单，质量测试与质量标准则用于定量分析和评价程序的质量。要考虑几种不同的度量标准。

• 质量测试

• 质量标准

10.5 提高可维护性的方法

• 建立明确的软件质量目标和优先级
• 使用提高软件质量的技术和工具
• 进行明确的质量保证审查
• 选择可维护的程序设计语言
• 改进程序的文档

考试常见题型（天大）
一、名词解释（4分*5）
二、简答 （6分*5）
三、设计题（15分*2）
四、建模（10分*2）

建模要求将给出的问题陈述进行分析，做出数据流图，并完成软件层次结构图，或者将给出的数据流程图直接转化为软件层次结构图。

由 sunxiaofei 编辑，最后编辑时间为:2017-11-02 19:00:00
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名