软件维护.ppt

软件维护.ppt

《软件维护.ppt》由会员分享，可在线阅读，更多相关《软件维护.ppt（31页珍藏版）》请在冰豆网上搜索。

第8章软件维护产品交付后的修改软件维护三十年以前，软件维护（maintenance）被刻画为冰山。

在20世纪70年代的早期，维护冰山非常大，足以使一艘航空母舰沉没。

而今天，它已可以很容易的沉没整个海军！

现在软件开发机构要把70%的工作量用在维护巳有的软件上。

随着软件产品的增加，这个百分比还会提高！

这是因为我们主要依赖的软件已15年到20年的使用史。

即使这些程序的创建是采用当时最好的设计和最好的编码技术（大多数并非如此），它们创建时的主要关注点却是程序的规模和存储空间（因为当时的主要矛盾是机器的运算速度太慢和存储空间太小）。

然后，它们被移植到新的平台上，只是根据机器和操作系统技术方面的变化进行调整，并根据用户的需求作了增加。

所有这些，并没有对软件的整个体系结枸给予足够的关注和改进。

实际情况是：

我们仍然保持运行的软件，具有设计很差的结构、糟糕的编码、很差的逻辑和不完整的文档计算机软件不断修改是不可避免的，这是软件的基本特性。

因此，我们必须建立某些管理机制，来评价、控制和完成这些修改软件维护内容软件维护的分类软件维护的特点软件的可维护性软件的维护任务软件维护的副作用一、软件维护的分类1.改正性（corrective）维护（21%）2.适应性（adaptive）维护（25%）3.完善性（perfective）维护（50%）4.预防性（preventive）维护（4%）以上是1980年，从对487个软件开发机构进行调查研究的结果二、软件维护的特点直到现在，软件维护（产品交付后的修改）在软件工程整个过程中仍被大家忽视。

与计划和开发阶段相比较，有关软件维护方面的文献资料极少，这个问题的研究和有关生产数据的收集都很进行得很少。

同时，几乎没有提出什么技术手段和方法

（一）软件工程与软件维护的关系

（二）维护费用30年代维护费用为软件总支出的3040%，80年代上升到60%，90年代中期许多开发机构软件费用的预算中有80%用于软件维护，现在更高。

这是有形的代价，其它无形的代价是无法估量的据报导开发一行代码需要25美元，而维护一行代码则需要1000美元。

Belady和Lchman提出了一种维护工作量模型：

M=P+K（c+d）其中：

M-用于维护工作的总的工作量；P-生产性的工作量；K-经验常数；c-复杂程度的量度，如未采用结构化设计和缺少文档所引起的复杂性；d-对该软件熟悉的程度（三）维护中的问题

（1）1.读懂他人写的程序通常相当困难，特别一些非结构化程序。

如果只有代码，而没有说明文档，那问题将会非常严重2.软件人员经常流动，所以当要求对软件进行维护时，不可能依靠原开发人员提供对软件的解释3.没有文挡或文档严重不足。

认识到软件必须编制文档是第一步；第二步是文档必须是可以理解的。

同时还要与源程序代码相一致，否则没有任何价值维护中的问题

（2）4.绝大多数软件在设计时，不考虑以后可能要修改。

除非采用功能独立的模块化设计。

否则，软件修改将是困难的，而且还容易引入新的错误5.通过多种版本的发行，要追踪软件的演化变得很困难，甚至不可能。

而修改又没有足够的文档作依据6.追踪软件的过程建立，非常困难或根本做不到7.维护被看作是毫无吸引人的工作，主要是因为维护工作经常遭受挫折三、软件的可维护性上面所提到的软件维护的各种特点都受到软件可维护性（maintainability）的影响软件可维护性的定义：

软件能够被理解、改正、适应和完善，以适应新的环境的难易程度因此，我们始终要强调的是：

要在软件工程的各个步骤中，提高软件的可维护性是一个关键目标

（一）控制因素

（1）软件最终的可维护性受许多因素的影响。

很显然，在设计、编码和测试中稍有疏忽，就会对软件可维护性带来不良影响。

即使在上述步骤中小心谨慎，低劣的软件配置也会产生同样的影响。

除了与开发方法有关的因素外，Kopetz还提出了下列一些与开发环境有关的因素：

控制因素

（2）1.合格的软件开发人员2.可理解的系统结构3.系统处理容易4.使用标准的编程语言5.使用标准的操作系统6.标准化的文档结构7.测试用例的有效性8.系统自身拥有的纠错工具9.易于维护的计算机10。

如果把软件看作是一个将来不可避免地要改动的系统部件。

那么，生产出具有良好可维护性软件的概率将会显著地增加。

这或许是最重要的因素

（二）定量度量Gilb提出了一些与维护工作量有关的可维护性量度：

1.问题确定时间2.管理延迟时间3.维护工具收集时间4.问题分析时间5.规格说明修改时间6.改正或修改活动时间7.局部测试时间8.全部测试时间9.维护评审时间10.整个恢复时间除了这些面向时间的量度以外，可维护性也可以通过设计结构和软件复杂性间接度量。

这些研究表明：

程序结构和逻辑复杂性对软件可维护性有很大关系（三）评审可维护性应该是所有软件的一个基本特性。

因此。

必须在软件开发的各个阶段对上述有影响的因素都要加以考虑，并在评审过程中分别考虑它们的可维护性：

1.需求评审时，对将来可能要完善和修改的部分应加以说明，并在讨论可移植性问题时，应考虑系统接口对软件可维护性带来的影响2.设计评审时，数据设计、体系结构设计、过程设计及接口设计是否易于修改，以及整个设计质量都要作出评价3.编码评审时，则应强调编程风格和内部文挡这两个影响可维护性的因素4.测试评审时，每个测试步骤都应对预防性维护作出提示在测试结束时，还应进行正式的可维护性评审，以确保软件配置的所有成分是完整的和可理解的。

最后还要对修改控制的文档进行归档在完成软件各项任务之后，还应对软件维护任务本身进行评审四、软件维护的任务早在维护申请提出之前，与软件维护有关的工作就已经开始首先，要建立一个机构其次，对每一个维护申请写出报告，并对其过程进行评价第三，要对每一个维护申请制定一个规范化的工作程序。

此外，还要为维护活动建立记录保管程序和制订评审的准则

（一）维护机构

（二）编写报告1.软件维护申请表MRF（maintenancerequestform），又称软件问题报告SPR（softwareproblemreport）。

由用户根据维护活动的要求写出2.软件修改报告SCR（softwarecorrectreport）。

由软件开发机构写出:

（1）为满足MRF要求所需要的工作量

（2）修改要求的性质（3）该申请的优先次序（4）修改后的结果在拟定详细维护计划之前，应将SCR提交修改控制部门批准（三）维护流程

（1）维护流程

（2）不论哪一种类型的维护都要进行相同的技术工作：

1.修改软件设计2.评审3.必要的代码修改4.单元测试5.组装测试，包括使用早先测试用例的回归测试6.确认测试7.评审软件维护就是软件工程的循环实际应用，即二次软件开发。

不同的是维护类型不同、重点不同，但整个方法没有变维护流程中最后一项工作是评审，即重新验证和确认软件配置所有成分都有效，并确保在实际上完全满足MRF的要求维护流程（3）软件维护任务完成以后，还要对维护工作进行状态评审。

通常，这样的评审应回答以下问题：

1.在现行情况下，设计、编码或测试中，哪些方面还可以改进2.哪些维护资源，本应用上，却没有用上3.什么是这次维护工作的主要障碍或次要障碍4.报告的申请类型，是否提出了要进行预防性维护维护状态评审工作的状态评审，对今后的维护工作有重要影响，对软件开发机构进行有效的管理就更为重要了（四）记录保存

（1）在维护记录保存中，遇到的主要问题是应该记录哪些数据，Swanson提出了一张项目表：

1.程序标识2.源语句数目3.机器代码指令数目4.使用的编程语言5.程序安装日期6.程序安装以来运行的次数7.与第6项有关的故障处理次数8.程序修改的级别和标识9.由于程序修改而增加的源语句数目记录保存

（2）10.由于程序修改而删去的源语句数目11.每项修改的所需的人-时数12.程序修改日期13.软件工程师的标识14.MRF的标识15.维护类型16.维护开始和结束日期17.用了维护所需人-时累计数18.与所完成维护有关的效益应把这些项目作为维护数据库的基础，以便对它们进行评价。

对于每一项维护工作都应该收集上述数据记录保存（3）关于预测维护工作量的度量，Vessey和Weber对400个Cobol程序研究发现：

程序的复杂性和编程风格是改正性维护发生的最重要影响因素。

他们以COCOMO模型为基础，给出了人-日定量预测模型：

E.maint=ACTx2.4xKLOC1.05其中：

E.maint为每年软件维护工作量的开销ACT为每年的更改次数，定义为：

ACT=系统承受维护的KLOC/CICI为一年维护中修改或增加的代码指令数KLOC为千行代码数尽管这项研究成果必须谨慎使用，但该定量模型还是给管理提供了一个控制因素，这正是软件维护所忽视的（五）评价Swanson给出了一张度量项目的简表：

1.每个程序运行故障处理的平均数2.用于每种类型维护工作的人-时总数3.每种程序、每种语言、每种维护类型所进行的程序修改平均数4.由于维护而增加或删除一条源语句所花费的人-时平均数5.每种语言所花费的人-时平均数6.一份MRF周转时间的平均数7.各种类型维护申请的百分数这七项量度描述可以提供一份定量的框架。

根据它们可以决策：

开发技术、语言选择、预测项目维护的工作量、资源分配及维护工作的评价五、软件维护的副作用软件维护的副作用（maintenancesideeffects）：

在复杂的逻辑过程中，每修改一次，都可能使潜在的错误增加。

设计文档和细心的回归测试都有助于消除错误。

但仍然可能遇到维护的副作用Freedman和Weinberg定义了三类主要副作用：

（一）修改代码的副作用

（二）修改数据的副作用（三）修改文档的副作用

（一）修改代码的副作用使用编程语言源代码与机器通信，产生副作用的机会很多：

1.删除或修改一个子程序2.删除或改变一个语句标号3.删除或改变一个标识符4.为改进执行性能所作的修改5.改变文件的打开或关闭6.改变逻辑运算符7.把设计修改翻译为主代码的修改8.对边界条件的逻辑测试所作的修改

（二）修改数据的副作用数据副作用产生于对软件数据结构的修改。

维护中，经常要对数据结构的个别元素或结构本身进行修改。

当数据改变时，原有的软件设计可能对这些数据不再适应，从而产生错误：

1.重新定义局部或全程常量2.重新定义记录或文件格式3.增加或减小一个数组或高阶数据结构的大小4.修改全程数据5.重新初始化控制标记或指针6.重新排列I/O或子程序的自变量完善的设计文挡，可以限制数据的副作用。

这种文档应当描述了数据结构，并提供了一种把数据元素、记录、文件和其它结构与软件模块联系起来的交叉对照表（三）修改文档的副作用维护应当着眼于整个软件配置，而不只是源代码的修改。

如果，源代码的修改没有反映在设计文档或用户手册中，就会产生文档的副作用对软件的任何修改，都必须对其支持的技术文档进行更新。

设计文档不能正确地反映软件的当前状态，可能比完全没有文挡更坏在软件再次交付使用前，对整个软件配置进行评审将能大大减少文档的副作用。

实际中，某些维护申请只是指出用户文档不够清楚，并不要求修改软件设计或源代码。

此时，只对文档进行维护即可六，ISO/IEC12207中的维护过程维护过程是软件维护人员所从事的一系列活动，其目的是在保持软件整体性能的同时，修改它，使其达到某一需求。

直到其退役才告终止从维护方式上讲：

有三种维护（改正性、适应性和改善性）。

维护过程包含的活动有：

问题分析和修改分析、修改/实施、对维护的评审/验收、软件移植、软件的退役等维护过程的同时，还贯穿软件过程中其它过程的实施。

维护人员通过管理过程管理维护过程、通过裁剪过程裁剪维护过程中的活动、通过改善过程参与维护过程的管理、通过支持过程中的各个过程实施维护过程中的文档编制/评审/质量保证等。

当进入某个活动时，维护过程可能需进入开发过程（如实施软件的修改时），这时维护人员即是那里的开发人员。

结束语维护过程不可缺少。

维护工作的好坏直接影响软件产品的质量和劳动生产率。

任何轻视和忽视维护过程都是错误的