软件维护概述

---

---

软件维护如今已成为SDLC中广泛接受的一部分。它代表软件产品交付后所做的所有修改和更新。修改的原因有很多，其中一些简要介绍如下。

• 市场状况 - 随着时间的推移而变化的政策，例如税收和新引入的约束条件（例如，如何维护簿记），可能会触发修改的需求。

• 客户需求 - 随着时间的推移，客户可能会要求软件中添加新功能。

• 主机修改 - 如果目标主机的任何硬件和/或平台（例如操作系统）发生变化，则需要更改软件以保持适应性。

• 组织变革 - 如果客户端发生任何业务层面的变化，例如组织规模缩减、收购另一家公司、组织进军新业务，则可能需要修改原始软件。

维护类型

在软件生命周期中，维护类型可能因其性质而异。它可能只是一些用户发现的错误的例行维护任务，也可能根据维护规模或性质本身就是一个重大事件。以下是根据其特征的一些维护类型。

• 纠正性维护 - 这包括为了纠正或修复由用户发现或由用户错误报告得出的问题而进行的修改和更新。

• 适应性维护 - 这包括应用的修改和更新，以使软件产品保持最新状态并适应不断变化的技术和商业环境。

• 完善性维护 - 这包括为了使软件在较长时间内保持可用而进行的修改和更新。它包括新功能、新的用户需求，以改进软件并提高其可靠性和性能。

• 预防性维护 - 这包括进行修改和更新以防止软件的未来问题。其目的是解决目前不重要但将来可能导致严重问题的问题。

维护成本

报告表明，维护成本很高。一项关于估算软件维护成本的研究发现，维护成本高达整个软件过程周期成本的67%。

平均而言，软件维护成本占所有SDLC阶段的50%以上。有多种因素导致维护成本居高不下，例如

影响维护成本的现实因素

• 任何软件的标准使用年限被认为是10到15年。
• 较旧的软件，旨在在内存和存储容量较小的慢速机器上运行，无法在现代硬件上与新推出的增强型软件相抗衡。
• 随着技术的进步，维护旧软件变得越来越昂贵。
• 大多数维护工程师都是新手，并使用试错法来纠正问题。
• 通常，所做的更改很容易损害软件的原始结构，从而使任何后续更改变得困难。
• 更改通常没有记录，这可能会在将来导致更多冲突。

影响维护成本的软件端因素

• 软件程序结构
• 编程语言
• 对外部环境的依赖性
• 员工可靠性和可用性

维护活动

IEEE为顺序维护过程活动提供了一个框架。它可以以迭代方式使用，并且可以扩展，以便可以包含自定义项目和流程。

这些活动与以下每个阶段密切相关

• 识别与跟踪 - 它涉及识别修改或维护需求的活动。它由用户生成，或者系统本身可能通过日志或错误消息进行报告。在此，还对维护类型进行分类。

• 分析 - 分析修改对系统的影响，包括安全影响。如果可能的影响严重，则寻找替代解决方案。然后将一组所需的修改具体化为需求规范。分析修改/维护的成本并得出估计值。

• 设计 - 根据上一阶段设置的需求规范，设计需要替换或修改的新模块。创建测试用例以进行验证。

• 实现 - 在设计步骤中创建的结构化设计的帮助下对新模块进行编码。每个程序员都应并行进行单元测试。

• 系统测试 - 在新创建的模块之间进行集成测试。还在新模块和系统之间进行集成测试。最后，按照回归测试程序对整个系统进行测试。

• 验收测试 - 在内部测试系统后，在用户的帮助下对其进行验收测试。如果在此状态下，用户抱怨一些问题，则会解决这些问题或记录下来以便在下次迭代中解决。

• 交付 - 验收测试后，系统将通过小型更新包或全新安装系统的方式部署到整个组织。在软件交付后，最终测试将在客户端进行。

  如果需要，除了用户手册的纸质副本外，还提供培训设施。

• 维护管理 - 配置管理是系统维护的重要组成部分。它借助版本控制工具来控制版本、半版本或补丁管理。

软件再工程

当我们需要更新软件以使其保持当前市场水平，而不会影响其功能时，这称为软件再工程。这是一个彻底的过程，其中软件的设计发生变化并且程序被重写。

遗留软件无法与市场上最新的技术保持同步。随着硬件变得过时，软件更新变得令人头疼。即使软件随着时间的推移而老化，其功能也不会消失。

例如，最初 Unix 是用汇编语言开发的。当 C 语言出现时，Unix 被用 C 重构，因为用汇编语言工作很困难。

除此之外，有时程序员会注意到软件的某些部分比其他部分需要更多的维护，并且也需要进行再工程。

再工程过程

• 确定要再工程的内容。是整个软件还是其中一部分？
• 执行逆向工程，以获取现有软件的规范。
• 如果需要，重构程序。例如，将面向函数的程序更改为面向对象的程序。
• 根据需要重构数据。
• 将前向工程概念应用于获取再工程软件。

在软件再工程中使用了一些重要的术语

逆向工程

它是一个通过彻底分析和理解现有系统来实现系统规范的过程。此过程可以看作是反向SDLC模型，即我们尝试通过分析较低抽象级别来获得较高抽象级别。

现有系统是先前实现的设计，我们对此一无所知。然后，设计人员通过查看代码并尝试获取设计来进行逆向工程。有了设计，他们试图得出规范。因此，从代码反向到系统规范。

程序重构

它是一个重构和重建现有软件的过程。它完全是关于重新排列源代码，无论是在相同的编程语言中还是从一种编程语言更改为另一种编程语言。重构可以包括源代码重构和数据重构，或者两者兼而有之。

重构不会影响软件的功能，但会增强可靠性和可维护性。可以更改或更新经常导致错误的程序组件。

可以通过重构消除软件对过时硬件平台的依赖性。

前向工程

前向工程是从手头的规范中获取所需软件的过程，这些规范是通过逆向工程获得的。它假设过去已经进行了一些软件工程。

前向工程与软件工程过程相同，只有一点区别——它始终在逆向工程之后执行。

组件可重用性

组件是软件程序代码的一部分，它在系统中执行独立的任务。它可以是一个小模块或子系统本身。

示例

Web 上使用的登录过程可以被视为组件，软件中的打印系统可以被视为软件的组件。

组件具有很高的功能内聚性和较低的耦合率，即它们独立工作并且可以在不依赖其他模块的情况下执行任务。

在OOP中，对象的设计非常具体，并且在其他软件中使用的可能性较小。

在模块化编程中，模块被编码以执行特定任务，这些任务可以在许多其他软件程序中使用。

有一个全新的垂直领域，它基于软件组件的重用，被称为基于组件的软件工程（CBSE）。

重用可以在不同的层级进行

• 应用级 - 将整个应用程序用作新软件的子系统。

• 组件级 - 使用应用程序的子系统。

• 模块级 - 重用功能模块。

  软件组件提供接口，可用于在不同组件之间建立通信。

重用过程

可以采用两种方法：要么保持需求不变并调整组件，要么保持组件不变并修改需求。

• 需求规格说明 - 在现有系统、用户输入或两者结合的帮助下，指定软件产品必须符合的功能和非功能需求。

• 设计 - 这也是标准的SDLC过程步骤，其中需求以软件术语定义。创建整个系统及其子系统的基本架构。

• 指定组件 - 通过研究软件设计，设计人员将整个系统划分为更小的组件或子系统。一个完整的软件设计变成了大量组件协同工作的一个集合。

• 搜索合适的组件 - 设计人员参考软件组件库，根据功能和预期的软件需求搜索匹配的组件。

• 集成组件 - 将所有匹配的组件打包在一起，形成完整的软件。