第8章维护-CSDN博客

本文链接：https://blog.csdn.net/m0_69135494/article/details/140314905

维护的基本任务是保证软件在一个相当长的时期能够正常运行。

软件工程学的主要目的就是要提高软件的可维护性，减少维护的代价。

8.1软件维护的定义

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

改正性维护：诊断和改正错误的过程。

适应性维护：为了和变化了的环境适当地配合而进行的修改软件的活动。

完善性维护：在使用软件的过程中用户往往提出增加新功能或修改已有功能的建议，实现这些要求的过程。

预防性维护：给未来的改进奠定更好的基础而修改软件。

8.2软件维护的特点

8.2.1结构化维护与非结构化维护差别巨大

1.非结构化维护

如果软件配置的唯一成分是程序代码，那么维护活动从艰苦地评价程序代码开始，而且常常由于程序内部文档不足而使评价更困难，对于软件结构、全程数据结构、系统接口、性能和（或）设计约束等经常会产生误解，而且对程序代码所做的改动的后果也是难于估量的：因为没有测试方面的文档，所以不可能进行回归测试。

因此，非结构化维护需要付出很大代价，这种维护方式是没有使用良好定义的方法学开发出来的软件的必然结果。

2.结构化维护

如果有一个完整的软件配置存在，那么维护工作从评价设计文档开始，确定软件重要的结构特点、性能特点以及接口特点；估量要求的改动将带来的影响，并且计划实施途径。然后首先修改设计并且对所做的修改进行仔细复查。接下来编写相应的源程序代码；使用在测试说明书中包含的信息进行回归测试。

结构化维护是软件开发的早期应用软件工程方法学的结果

8.2.2维护代价高昂

维护费用只不过是软件维护的最明显的代价。在维护时可能还存在其他无形的代价。

下述是五种代价：

因为可用的资源必须供维护任务使用，以致耽误甚至丧失了开发的良机
当看来合理的有关修改的要求不能及时满足时将引起用户不满。
由于维护时的改动，在软件中引入了潜伏的错误，从而降低了软件的质量。
当必须把软件工程师调去从事维护工作时，将在开发过程中造成混乱。
软件的生产率的大幅度下降（这种情况在维护旧程序时常常遇到）。

用于维护工作的劳动可以分成生产性活动（例如，分析评价，修改设计和编写程序代码等）和非生产性活动（例如，理解程序代码的功能，解释数据结构、接口特点和性能限度等）。下述表达式给出维护工作量的一个模型：

M＝P+K×exp(c－d)；

M是维护用的总工作量，P是生产性工作量，K是经验常数，c是复杂程度（非结构化设计和缺少文档都会增加软件的复杂程度），d是维护人员对软件的熟悉程度。

上面的模型表明，如果软件的开发途径不好（即没有使用软件工程方法学），而且原来的年发人员不能参加维护工作，那么维护工作量和数用将指数地增加。

8.2.3维护的问题很多

与软件维护有关的绝大多数问题，都可归因于软件定义和软件开发的方法有缺点。

下面是和软件维护有关的部分问题。

理解别人写的程序通常非常困难
需要维护的软件往往没有合格的文档。
当要求对软件进行维护时，不能指望由开发人员给人们仔细说明软件。（由于维护阶段持续的时间很长原来写程序的人已经不在附近了）
绝大多数软件在设计时没有考虑将来的修改。
软件维护不是一项吸引人的工作。

8.3软件维护的过程

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

过程：建立维护组织，确定维护报告，规定维护的事件流，保存维护记录，评价维护活动。

1.维护组织

虽然通常并不需要建立正式的维护组织，但是，即使对于一个小的软件开发团体而言，非正式地委托责任也是绝对必要的。

2.维护报告

应该用标准化的格式表达所有软件维护要求。

软件维护人员通常给用户提供空白的维护要求表 ——有时称为软件问题报告表，这个表格由要求一项维护活动的用户填写。

3.维护的事件流

不管维护类型如何，都需要进行同样的技术工作。这些工作包括修改软件设计、复查、必要的代码修改、单元测试和集成测试（包括使用以前的测试方案的回归测试）、验收测试和复审。

在完成软件维护任务之后，进行处境复查常常是有好处的。一般说来，这种复查试图回答下述问题。

在当前处境下设计、编码或测试的哪些方面能用不同方法进行?
哪些维护资源是应该有而事实上却没有的?
对于这项维护工作什么是主要的障碍?
要求的维护类型中有预防性维护吗?

4.保存维护记录

值得保存的数据：

①程序标识；②源语句数；③机器指令条数；④使用的程序设计语言；⑤程序安装的日期；⑥自从安装以来程序运行的次数；⑦自从安装以来程序失效的次数；⑧程序变动的层次和标识；⑨因程序变动而增加的源语句数；⑩因程序变动而删除的源语句数；⑾每个改动耗费的人时数；⑿程序改动的日期；⒀软件工程师的名字；⒁维护要求表的标识；⒂维护类型；⒃维护开始和完成的日期；⒄累计用于维护的人时数；⒅与完成的维护相联系的纯效益。

5.评价维护活动

缺乏有效的数据就无法评价维护活动，如果已经开始保存维护记录了，则可以对维护工作做一些定量度量。至少可以从下述7个方面度量维护工作。

每次程序运行平均失效的次数。
用于每一类维护活动的总人时数。
平均每个程序、每种语言、每种维护类型所做的程序变动数。
维护过程中增加或删除一个源语句平均花费的人时数。
维护每种语言平均花费的人时数。
一张维护要求表的平均周转时间。
不同维护类型所占的百分比。

8.4软件的可维护性

可维护性：维护人员理解、改正、改动或改进这个软件的难易程度。

8.4.1决定软件可维护性的因素

1.可理解性

读者理解软件的结构、功能、接口和内部处理过程的难易程度。

2.可测试性

诊断和测试的容易程度取决于软件容易理解的程度。

对于程序模块来说，可以用程序复杂度来度量它的可测试性。

3.可修改性

软件容易修改的程度和本书第5章讲过的设计原理和启发规则直接有关。耦合、内聚、信息隐藏、局部化、控制域与作用域的关系等，都影响软件的可修改性。

4.可移植性

可移植性定义：把程序从一种计算环境（硬件配置和操作系统）转移到另一种计算机环境的难易程度。

5.可重用性

重用定义：同一事物不做修改或稍加改动就在不同环境中多次重复使用。

通常，可重用的软件构件在开发时都经过很严格的测试，可靠性比较高，因此，软件中使用的可重用构件越多，软件的可靠性越高，改正性维护需求就越少。
很容易修改可重用的软件构件使之再茨应用在新环境中，因此，软件中使用的可重用构件越多，适应性和完善性维护也就越容易。

8.4.2文档

文档是影响软件可维护性的决定因素。

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

用户文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的;系统文档描述系统设计、实现和测试等各方面的内容

总地说来，软件文档应该满足下述要求。

描述如何使用这个系统。
描述怎样安装和管理这个系统。
描述系统需求和设计。
描述系统的实现和测试，以便使系统成为可维护的。

8.4.3可维护性复审

代码复审：强调编码风格和内部说明文档这两个影响可维护性的因素。

配置复审：在测试结束时进行最正式的可维护性复审。

配置复审的目的：保证软件配置低所有成分上完整的、一致的和可理解的。

在完成了每项维护工作之后，都应该对软件维护本身进行仔细认真的复审。维护应该针对整个软件配置，不应该只修改源程序代码。

8.5预防性维护

某些老程序仍然在为用户服务，但是，当初开发这些程序时并没有使用软件工程方法学来指导，因此，这些程序的体系结构和数据结构都很差，文档不全甚至完全没有文档，曾经做过的修改也没有完整的记录。

为了修改这类程序以适应用户新的或变更的需求，有以下几种做法可供选择。

反复多次地做修改程序的尝试，以实现所要求的修改。（这种做法很盲目）
通过仔细分析程序尽可能多地掌握程序的内部工作细节，以便更有效地修改它。
在深入理解原有设计的基础上，用软件工程方法重新设计、重新编码和测试那些需要变更的软件部分。（局部的再工程）
以软件工程方法学为指导，对程序全部重新设计、重新编码和测试，为此可以使用 CASE工具（逆向工程和再工程工具）来帮助理解原有的设计。（这种做法称为软件再工程）

预防性维护方法是中 Miller提出来的，他把这种方法定义为“把今天的方法学应用到昨天的系统上，以支持明天的需求。”

8.6软件再工程过程

再工程范型是一个循环模型。这意味着作为该范型的组成部分的每个活动都可能被重复，而且对于任意一个特定的循环来说，过程可以在完成任意一个活动之后终止。下面简要地介绍该模型所定义的6类活动。

1.库存目录分析

每个软件组织都应该保存其拥有的所有应用系统的库存目录。该目录包含关于每个应用系统的基本信息。

每一个大的软件开发机构都拥有上百万行老代码，它们都可能是逆向工程或再工程的对象。但是，某些程序并不频繁使用而且不需要改变，此外，逆向工程和再工程工具尚不成熟，目前仅能对有限种类的应用系统执行逆向工程或再工程，代价又十分高昂，因此，对库中每个程序都做逆向工程或再工程是不现实的。下述3类程序有可能成为预防性维护的对象。