第八章：维护

第八章：维护

一、软件工程的目的

软件工程的主要目的就是要提高软件的可维护性，减少软件维护所需要的工作量，降低软件系统的总成本。

二、软件维护的概念

1.定义

• 软件维护是在软件已经交付使用后，为了改正错误或满足新的需要而修改软件的过程，是软件生命周期的最后一个阶段，其基本任务是保证软件在一个相当长的时期能够正常运行。

2.分类

• (1)改正性维护
  在任何大型程序的使用期间，用户必然会发现程序错误，并且把他们遇到的问题报告给维护人员。把诊断改正错误的过程称为改正性维护。
  (2)适应性维护
  适应性维护，也就是为了和变化了的环境适当地配合而进行的修改软件的活动，是既必要又经常的维护活动。
  (3)完善性维护
  为了满足用户在使用团建过程中提出的新功能或者修改已有功能的建议，需要进行完善性维护。这项维护活动通常占软件维护工作的大部分。
  (4)预防性维护
  当为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件，这项维护活动通常称为预防性维护。
  注意：上述4类维护活动都必须应用于整个软件配置，维护软件文档与维护软件的可执行代码是同样重要的。

三、软件维护的特点

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

• (1)非结构化维护
  ①流程
  a.软件配置的唯一成分是程序代码，维护活动从艰苦地评价程序代码开始；
  b.由于程序内部文档不足，而对于软件结构、全程数据结构、系统接口、性能和设计约束等会产生误解；
  c.对程序代码所做的改动的后果是难于估量的；
  d.没有测试方面的文档，不可能进行回归测试。
  ②特点
  非结构化维护需要付出很大代价，这种维护方式是没有使用良好定义的方法学开发出来的软件的必然结果。
  (2)结构化维护
  ①流程
  a.有一个完整的软件配置存在，维护工作从评价设计文档开始：
  b.确定软件重要的结构特点、性能特点以及接口特点；
  c.估量要求的改动将带来的影响，并且计划实施途径；
  d.修改设计并且对所做的修改进行仔细复查；
  e.编写相应的源程序代码；
  f.使用在测试说明书中包含的信息进行回归测试；
  g.把修改后的软件再次交付使用。
  ②特点
  结构化维护是在软件开发的早期应用软件工程方法学的结果。有了软件的完整配置能减少精力的浪费并且能提高维护的总体质量。

2.维护的代价高昂

• 软件维护中无形的代价有：
  (1)因为可用的资源必须供维护任务使用，以致耽误甚至丧失了开发的良机。
  (2)当看来合理的有关改错或修改的要求不能及时满足时将引起用户不满。
  (3)由于维护时的改动，在软件中引入了潜伏的错误，从而降低了软件的质量。
  (4)当必须把软件工程师调去从事维护工作时，将在开发过程中造成混乱。

3.维护存在的问题

• 与软件维护有关的绝大多数问题，都可归因于软件定义和软件开发的方法有缺点。在软件生命周期的头两个时期没有严格而又科学的管理和规划，几乎必然会导致在最后阶段出现问题。与软件维护有关的部分问题如下：
  (1)理解别人写的程序非常困难，而且困难程度随着软件配置成分的减少而迅速增加。
  (2)需要维护的软件往往没有合格的文档，或者文档资料显著不足。
  (3)当要求对软件进行维护时，不能指望由开发人员给人们仔细说明软件。
  (4)绝大多数软件在设计时没有考虑将来的修改。
  (5)软件维护不是一项吸引入的工作。

四、软件维护过程

1.定义

• 维护过程本质上是修改和压缩了的软件定义和开发过程。软件维护过程可以描述为：
  (1)建立一个维护组织；
  (2)确定报告和评价的过程；
  (3)为每个维护要求规定一个标准化的事件序列；
  (4)建立一个适用于维护活动的记录保管过程；
  (5)规定复审标准。

2.具体过程

• (1)维护组织
  每个维护要求都通过维护管理员转交给熟悉该产品的系统管理员去评价。系统管理员是被指定去熟悉一小部分产品程序的技术人员。系统管理员对维护任务做出评价之后，由变化授权人决定应该进行的活动。
  (2)维护报告
  ①维护要求表
  软件维护人员通常给用户提供空白的维护要求表(软件问题报告表),这个表格由要求一项维护活动的用户填写。由维护管理员和系统管理员评价用户提交的维护要求表。软件要求表是一个外部产生的文件，它是计划维护活动的基础，应该用标准化的格式表达所有软件维护要求。
  ②软件修改报告
  a.满足维护要求表中提出的要求所需要的工作量。
  b.维护要求的性质。
  c.这项要求的优先次序。
  d.与修改有关的事后数据。
  (3)维护的事件流
  图8-1描绘了由一项维护要求而引出的一串事件。
  维护过程需要的技术工作有：
  ①修改软件设计：
  ②复查；
  ③必要的代码修改；
  ④单元测试和集成测试；
  ⑤验收测试；
  ⑥复审；
  ⑦处境复查。
  (4)保存维护记录
  在保存维护记录阶段，值得保存的数据：
  ①程序标识；
  ②源语句数；
  ③机器指令条数；
  ④使用的程序设计语言；
  ⑤程序安装的日期；
  ⑥自从安装以来程序运行的次数；
  ⑦自从安装以来程序失效的次数；
  ⑧程序变动的层次和标识；
  ⑨因程序变动而增加的源语句数；
  ⑩因程序变动而删除的源语句数；
  ⑩①每个改动耗费的人时数；
  ⑩②程程序改动的日期；
  ⑩③软件工程师的名字；
  ⑩④维护要求表的标识；
  ⑩⑤维护类型
  ⑩⑥维护开始和完成的日期；
  ⑩⑦累计用于维护的人时数；
  ⑩⑧与完成的维护相联系的纯效益。
  (5)评价维护活动
  ①度量标准
  a.每次程序运行平均失效的次数。
  b.用于每一类维护活动的总人时数。
  a.平均每个程序、每种语言、每种维护类型所做的程序变动数。
  d.维护过程中增加或删除一个源语句平均花费的人时数。
  e.维护每种语言平均花费的人时数。
  f.一张维护要求表的平均周转时间。
  g.不同维护类型所占的百分比。
  ②作用
  根据对维护工作定量度量的结果，可以做出关于开发技术、语言选择、维护工作量规划、资源分配及其他许多方面的决定，而且可以利用这样的数据去分析评价维护任务。

  • 图8.1 维护阶段的事件流
    

五、软件的可维护性

1.定义

• 可维护性指的是维护人员理解、改正、改动或改进这个软件的难易程度。提高可维护性是支配软件工程方法学所有步骤的关键目标。

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

• 维护就是在软件交付使用后进行的修改，修改之前必须理解待修改的对象，修改之后应该进行必要的测试，以保证所做的修改是正确的。如果是改正性维护，还必须预先进行调试以确定错误的具体位置。决定软件可维护性的因素主要有下述5个：
  (1)可理解性
  ①定义
  软件可理解性表现为外来读者理解软件的结构、功能、接口和内部处理过程的难易程度。
  ②影响因素
  a.模块化(模块结构良好，高内聚，松耦合);
  b.详细的设计文档；
  c.结构化设计；
  d.程序内部的文档；
  e.高级程序设计语言等。
  (2)可测试性
  诊断和测试的容易程度取决于软件容易理解的程度。
  ①影响因素
  a.良好的文档；
  b.软件结构；
  c.可用的测试工具和调试工具；
  d.以前设计的测试过程。
  ②要求
  维护人员需要得到在开发阶段用过的测试方案，以便进行回归测试。在设计阶段应该尽力把软件设计成容易测试和容易诊断的。
  ③衡量标准
  对于程序模块来说，可以用程序复杂度来度量它的可测试性。模块的环形复杂度越大，可执行的路径就越多，全面测试它的难度就越高。
  (3)可修改性
  耦合、内聚、信息隐藏、局部化、控制域与作用域的关系等，都影响软件的可修改性。
  (4)可移植性
  ①定义
  软件可移植性是指把程序从一种计算环境(硬件配置和操作系统)转移到另一种计算环境的难易程度。
  ②提高可移植性的方法
  把与硬件、操作系统以及其他外部设备有关的程序代码集中放到特定的程序模块中，可以把因环境变化而必须修改的程序局限在少数程序模块中，从而降低修改的难度，提高可移植性。
  (5)可重用性
  ①定义
  重用是指同一事物不做修改或稍加改动就在不同环境中多次重复使用。
  ②对可维护性的影响
  a.提高软件可靠性，较少改正性维护
  可重用的软件构件在开发时都经过很严格的测试，可靠性比较高，且在每次重用过程中都会发现并清除一些错误，构件将变成实质上无错误的。
  b.降低适应性和完善性维护的难度
  很容易修改可重用的软件构件使之再次应用在新环境中。

3.文档

• (1)重要性
  文档是影响软件可维护性的决定因素。由于长期使用的大型软件系统在使用过程中必然会经受多次修改，所以文档比程序代码更重要。
  (2)特点
  ①必须描述如何使用这个系统，没有这种描述时即使是最简单的系统也无法使用。
  ②必须描述怎样安装和管理这个系统。
  ③必须描述系统需求和设计。
  ④必须描述系统的实现和测试，以便使系统成为可维护的。
  (3)分类
  软件系统的文档可以分为用户文档和系统文档两类。
  ①用户文档
  用户文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的。文档的结构方式应该使用户能够方便地根据需要阅读有关的内容。内容包括：
  a.功能描述；
  b.安装文档；
  c.使用手册；
  d.参考手册；
  e.操作员指南。
  ②系统文档
  系统文档是指从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档。描述系统设计、实现和测试的文档对于理解程序和维护程序来说是极端重要的。

4.可维护性复审

• (1)可维护性
  可维护性是所有软件都应该具备的基本特点，必须在开发阶段保证软件具有可理解性、可测试性、可修改性、可重用性、可移植性。在软件工程过程的每一个阶段都应该考虑并努力提高软件的可维护性，在每个阶段结束前的技术审查和管理复审中，应该着重对可维护性进行复审。
  (2)复审的任务
  ①需求分析阶段的复审
  a.对将来要改进的部分和可能会修改的部分加以注意并指明；
  b.讨论软件的可移植性问题，并且考虑可能影响软件维护的系统界面。
  ②正式的和非正式的设计阶段的复审
  a.从容易修改、模块化和功能独立的目标出发，评价软件的结构和过程；
  b.对将来可能修改的部分预作准备。
  ③编码阶段
  a.强调编码风格和内部说明文档这两个影响可维护性的因素；
  b.尽量使用可重用的软件构件，如开发新的构件，也应该注意提高构件的可重用性。
  ④测试阶段
  a.保证软件配置的所有成分是完整的、一致的和可理解的；
  b.为便于修改和管理，进行编目归档。
  ⑤维护阶段
  保证维护是针对整个软件配置，不只是修改源程序代码。
  (3)复审的必要性
  在软件再次交付使用之前，对软件配置进行严格的复审，则可大大减少文档的问题。事实上，某些维护要求可能并不需要修改软件设计或源程序代码，只是表明用户文档不清楚或不准确，因此只需要对文档做必要的维护。

六、预防性维护

1.定义

• 预防性维护指的是把今天的方法学应用到昨天的系统上，以支持明天的需求。

2.方法

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

3.必要性

• (1)维护一行源代码的代价可能是最初开发该行源代码代价的14～40倍。
  (2)重新设计软件体系结构时使用了现代设计概念，对将来的维护可能有很大的帮助。
  (3)由于现有的程序版本可作为软件原型使用，开发生产率可大大高于平均水平。
  (4)用户具有较多使用该软件的经验，能够很容易地搞清新的变更需求和变更的范围。
  (5)利用逆向工程和再工程的工具，可以使一部分工作自动化。
  (6)在完成预防性维护的过程中可以建立起完整的软件配置。

七、软件再工程过程

1.典型软件再工程模型

• 典型的软件再工程过程模型如图8-2所示，该模型定义了6类活动。在某些情况下这些活动以线性顺序发生，但也并非总是这样。

  • 图8.2 软件再工程过程模型
    

2.六类活动

• (1)库存目录分析
  ①内容
  每个软件组织都应该保存其拥有的所有应用系统的库存目录。该目录包含关于每个应用系统的基本信息。
  ②预防性维护的对象
  对库中每个程序都做逆向工程或再工程是不现实的，下述3类程序有可能成为预防性维护的对象。
  a.预定将使用多年的程序。
  b.当前正在成功地使用着的程序。
  c.在最近的将来可能要做重大修改或增强的程序。
  ③方法
  仔细分析库存目录，按照业务重要程度、寿命、当前可维护性、预期的修改次数等标准，把库中的应用系统排序，从中选出再工程的候选者，然后明智地分配再工程所需要的资源。
  (2)文档重构
  ①建立文档非常耗费时间，选择有价值的程序重新建立文档。如果一个程序是相对稳定的，正在走向其有用生命的终点，而且可能不会再经历什么变化，那么，让它保持现状是一个明智的选择。
  ②采用"使用时建文档"的方法，只针对系统中当前正在修改的那部分建立完整文档。
  ③对于必须进行重构的关键业务，则应设法把文档工作减少到必需的最小量。
  (3)逆向工程
  软件的逆向工程是分析程序以便在比源代码更高的抽象层次上创建出程序的某种表示的过程，即逆向工程是一个恢复设计结果的过程，逆向工程工具从现存的程序代码中抽取有关数据、体系结构和处理过程的设计信息。
  (4)代码重构
  ①适用性
  针对某些老程序具有比较完整、合理的体系结构，但个体模块的编码方式却是难于理解、测试和维护的情况，可以重构可疑模块的代码。
  ②流程
  a.用重构工具分析源代码，标注出和结构化程序设计概念相违背的部分；
  b.然后重构有问题的代码；
  c.复审和测试生成的重构代码并更新代码文档。
  ③特点
  a.重构不修改整体的程序体系结构，仅关注个体模块的设计细节和在模块中定义的局部数据结构。
  b.重构扩展到模块边界之外并涉及软件体系结构，则变成了正向工程。
  (5)数据重构
  ①定义
  数据重构发生在相当低的抽象层次上，是一种全范围的再工程活动。数据重构始于逆向工程活动，分解当前使用的数据体系结构，必要时定义数据模型，标识数据对象和属性，并从软件质量的角度复审现存的数据结构。
  ②必要性
  对数据体系结构差的程序很难进行适应性修改和增强。对应用系统来说，数据体系结构比源代码本身对程序的长期生存力有更大影响。
  (6)正向工程
  ①定义
  正向工程(革新或改造)应用软件工程的原理、概念、技术和方法来重新开发某个现有的应用系统。在大多数情况下，被再工程的软件不仅重新实现现有系统的功能，而且加人了新功能和提高了整体性能。
  ②作用
  正向工程不仅从现有程序中恢复设计信息，还使用该信息去改变或重构现有系统，以提高其整体质量。

思维导图地址百度网盘地址