第八章维护.docx

第八章维护.docx

《第八章维护.docx》由会员分享，可在线阅读，更多相关《第八章维护.docx（10页珍藏版）》请在冰豆网上搜索。

第八章维护

第八章维护

一、概述P2

二、软件维护的定义

所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。

维护的类型有四种：

1、改正性维护（CorrectiveMaintenance）--诊断和改正错误的过程

在软件交付使用后，因开发时测试的不彻底、不完全，必然会有部分隐藏的错误遗留到运行阶段。

这些隐藏下来的错误在某些特定的使用环境下就会暴露出来。

为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，所进行的诊断和改正错误的过程就叫做改正性维护。

2、适应性维护（AdaptiveMaintenance）--为适应变化了的环境而进行的软件修改活动

在使用过程中，外部环境（新的硬、软件配置）、数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质）都可能发生变化。

为使软件适应这种变化，而去修改软件的过程就叫做适应性维护。

3、扩充与完善性维护（PerfectiveMaintenance）

在软件的使用过程中，用户往往会对软件提出增加新功能或修改已有功能、改善性能的要求。

为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。

这种情况下进行的维护活动叫做扩充与完善性维护。

4、预防性维护（PreventiveMaintenance）

预防性维护是为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。

预防性维护定义为：

采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编码和测试。

目前，这类维护活动相对比较少。

各类维护所占比例：

三、软件维护的特点

1、结构化维护与非结构化维护差别巨大

非结构化维护----软件配置的惟一成份是程序代码，维护活动从艰苦地评价程序代码开始。

P8

结构化维护----有一套完整的软件配置存在，维护工作从评价设计文档开始。

P9

2、影响软件维护的因素诸多

系统大小、程序设计语言、系统年龄、是否应用数据库技术、是否采用较先进的软件开发技术、开发时是否考虑将来的修改、其他因素（应用的类型、数学模型、任务的难度、开关与标记、IF嵌套深度、索引或下标数等）

3、软件维护的代价高昂

首先，软件维护需要的工作量很大，平均说来，大型软件的维护成本高达开发成本的4倍左右。

目前国外许多软件开发组织把60%以上的人力用于维护已有的软件，而且随着软件数量增多和使用寿命延长，这个百分比还在持续上升。

有形的软件维护成本是花费了多少钱，而无形的维护成本有更大的负面影响。

（1）一些合理的修复或修改请求不能及时安排，使得客户不满意；

（2）变更的结果引入新的故障，使得软件整体质量下降；

（3）把软件人员抽调到维护工作中，干扰了软件开发工作。

维护工作量的计算模型：

其中：

M是维护中消耗的总工作量

P是生产性工作量

K是一个经验常数

c是因缺乏好的设计和文档而导致复杂性的度量

d是维护人员对软件熟悉程度的度量

模型表明，如果使用了不好的软件开发方法（未按软件工程要求做），原来参加开发的人员或小组不能参加维护，则工作量（及成本）将按指数级增加。

4、影响软件维护的典型问题P14~16

难以读懂他人的程序

无文档或不全

软件人员流动性大

设计时未考虑修改需要，修改困难

维护工作无吸引力，缺乏成就感

难以跟踪软件的创建过程、软件版本的进化过程，软件的变化未在文档中反映出来

四、软件维护的过程

软件维护过程本质上是更改和压缩了的软件定义和开发过程。

1、前期工作

事实上，远在提出一项维护要求之前，与软件维护有关的工作已经开始了。

（机构、制度和标准）

首先要建立维护的机构

申明维护申请报告的提出过程及评价的过程

为每一个维护申请规定标准的处理步骤

建立维护活动的记录保管，并规定复审的标准

2、维护机构P18~19

维护要求

维护管理员系统管理员变化授权人

3、维护报告

应该由软件维护人员向用户提供标准化格式表格，使用户能表达所需软件维护要求；

维护申请报告或称软件问题报告，由申请维护的用户填写；

用户必须完整地说明产生错误的情况，包括输入数据、错误清单以及其它有关材料；

如果申请的是适应性维护或完善性维护，用户必须提出一份修改说明书，列出所有希望的改进。

维护申请报告将由维护管理员和系统管理员来研究处理。

他们应相应地做出软件修改报告，指明：

（1）所需修改变动的性质；

（2）申请修改的优先级；

（3）为满足某个维护申请报告，所需的工作量；

（4）预计修改后的状况。

软件修改报告应提交给变化授权人（修改负责人），经批准后才能进一步安排维护工作。

4、软件维护工作流程P23

尽管维护申请的类型不同，但都要进行同样的技术工作----是一次压缩了的软件工程。

（1）修改软件需求说明

（2）修改软件设计

（3）设计评审

（4）对源程序做必要的修改

（5）单元测试

（6）集成测试（回归测试）

（7）确认测试

（8）软件配置评审等。

在每次软件维护任务完成后要进行情况评审P26

5、保存维护记录P28

6、定量评价维护活动P29~30

五、软件的可维护性

1、软件可维护性概述

软件可维护性是指软件维护人员理解、纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充或压缩软件的难易程度；

可维护性、可使用性、可靠性是衡量软件质量的主要指标，也是用户十分关心的几个方面。

提高可维护性是支配软件工程方法学所有步骤的关键目标；

许多软件的维护十分困难，原因在于这些软件的文档不全、质量差，开发过程不注意采用好的方法，忽视程序设计风格等；

许多维护要求并不是因为程序中出错而提出的，而是为适应环境变化或需求变化而提出的----维护是不可避免的。

2、决定软件可维护性的因素

可理解性P33

可测试性P34

可修改性P35

可移植性P35

可重用性P36~37

3、软件的使用和维护与文档

文档是影响软件可维护性的决定因素，文档往往比代码更加重要；

软件文档应该满足下述要求：

（1）必须描述如何使用这个系统，没有这种描述时即使是最简单的系统也无法使用；

（2）必须描述怎样安装和管理这个系统；

（3）必须描述系统需求和设计；

（4）必须描述系统的实现和测试，以便使系统成为可维护的。

软件系统的文档可以分为用户文档和系统文档两类

（1）用户文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的；

用户文档是用户了解系统的第一步，它应该能使用户获得对系统的准确的初步印象。

文档的结构方式应该使用户能够方便地根据需要阅读有关的内容。

用户文档至少应该包括下述5方面的内容：

①功能描述；②安装文档；

③使用手册；④参考手册；

⑤操作员指南（如果需要有系统操作员的话）。

P40~41

上述内容可以分别作为独立的文档，也可以作为一个文档的不同分册，具体做法应该由系统规模决定。

（2）系统文档描述系统设计、实现和测试等各方面的内容。

P42*

4、可维护性复审

在软件生命周期的每个阶段，对软件的可维护性进行评价，为软件的可维护性打下基础，以使软件维护尽可能容易。

P196~197，P43~45

在完成了每项维护工作之后，都应该对软件维护本身进行仔细认真的复审。

（1）维护应该针对整个软件配置，不应该只修改源程序代码。

当对源程序代码的修改没有反映在设计文档或用户手册中时，就会产生严重的后果；

（2）每当对数据、软件结构、模块过程或任何其他有关的软件特点做了改动时，必须立即修改相应的技术文档。

不能准确反映软件当前状态的设计文档可能比完全没有文档更坏；

（3）用户通常根据描述软件特点和使用方法的用户文档来使用、评价软件。

如果对软件的可执行部分的修改没有及时反映在用户文档中，则必然会使用户因为受挫折而产生不满。

六、预防性维护

预防性维护方法是由Miller提出来的，他把这种方法定义为：

“把今天的方法学应用到昨天的系统上，以支持明天的需求。

”开发和维护者不应等待用户的维护申请,在条件具备时应该主动地进行预防性维护。

预防性维护对象：

预计若干年内将继续使用的程序

当今正成功使用的程序

最近的将来要进行大修改和完善的程序

七、软件再工程

1、概述

软件再工程，也叫做修理或再生，是一类软件工程活动。

它将逆向工程、重构和正向工程组合起来，将现存系统重新构造为新的形式。

它从已存在的程序中重新获得设计信息，而且使用这些信息来改建或重构现有的系统，同时加进新的功能或改善它的性能，以改进它的综合质量。

软件再工程不仅可以帮助软件机构降低软件演化的风险，而且可以使软件将来易于进一步变更，有助于推动软件维护自动化的发展。

2、逆向工程

术语“逆向工程”来自硬件领域，是一种通过对产品的实际样本进行分析，得出一个或多个关于这个产品的设计和制造规格的活动。

软件的逆向工程与此类似，通过对程序的分析导出更高抽象层次的表示，如从现存的程序中抽取数据、体系结构、过程的设计信息等，是一个设计恢复的过程。

逆向工程的过程如下图所示。

逆向工程的过程从源代码重构开始，将无结构的源代码转化为结构化的程序代码，这使得源代码易阅读，并为后续的逆向工程活动提供了基础。

抽取是逆向工程的核心，内容包括处理抽取、界面抽取和数据抽取。

处理抽取可在不同的层次对代码进行分析，即语句、语句段、模块、子系统、系统。

在进行更细的分析之前先应理解整个系统的整体功能。

由于GUI（图形用户界面）给系统带来越来越多的好处，进行用户界面的图形化已成为最常见的再工程活动之一。

界面抽取应先对现存用户界面的结构和行为进行分析和观察。

同时，还应从相应的代码中提取有关的附加信息。

数据抽取包括内部数据结构的抽取、全局数据结构的抽取、数据库结构的抽取等。

逆向工程的过程所抽取的信息，一方面可以提供给软件工程师以便在任何维护活动中使用这些信息；另一方面可以用来重构原来的系统，使新系统更易维护。

3、重构

软件重构是对源代码和/或数据进行修改，使其易于理解或维护，以适应（服务于）将来的变更。

通常，重构并不修改整个软件程序的体系结构，趋向于关注模块的细节。

如果重构扩展到模块边界之外并涉及软件体系结构，则重构就会变成正向工程。

软件重构中代码重构的目标是生成可提供相同功能但质量更高的程序。

需要代码重构的模块往往以难于理解、测试和维护的方式编码。

为此，用重构工具分析源代码，标注出和结构化程序设计概念相违背的部分，然后重构此代码，复审和测试生成的重构代码，更新代码的内部文档。

和代码重构不同，数据重构发生在相当低的抽象层次上，它是一种全范围的再工程的活动。

当数据结构较差时，其程序将难于进行适应性修改和增强。

数据重构在多数情况下以逆向工程活动为开始，来理解现存的数据结构，这称为数据分析。

数据分析完成后则开始数据重新设计，包括数据记录标准化、数据命名合理化、文件格式转换、数据库类型转换等等。

软件重构的好处，即：

提高了程序的质量，改善了软件的生产率，减少了维护的工作量，使软件易于测试和调试等等。

4、正向工程

正向工程也称为改造或再工程，它用从现存软件恢复设计中得到的信息去重构现存系统，以改善其整体质量。

在大多数情况下，被再工程的软件需重新实现现存系统的功能，并加入新功能和／或改善整体性能。

正向工程过程将应用软件工程的原则、概念和方法来重建现存应用。

由于软件的原型（现存系统）已经存在，正向工程的生产率将远高于平均水平；同时，又由于用户已对该软件有经验，因而正向工程过程可以很容易地确定新的需求和变化的方向。

这些优越性使得再工程比重新开发更有吸引力。

5、软件再工程过程模型所定义的6类活动

P198，P53，P55~61

实验：

12-16周，周2上午，4-401,402