软件维护概述

如今，软件维护已被广泛接受为 SDLC 的重要组成部分。它指软件产品交付后进行的各种修改和更新。有多种原因需要进行修改，以下简要列出其中一些：

• 市场条件 - 随着时间推移，政策会发生变化，例如税收政策或新引入的约束条件（如如何维护账簿），这些可能引发修改需求。

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

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

• 组织变更 - 如果客户端发生业务层面的变更，例如组织规模缩减、收购另一家公司或进入新业务领域，则可能需要对原有软件进行修改。

维护类型

在软件的生命周期中，维护类型可能因其性质而有所不同。它可能只是日常维护任务，例如用户发现的某些 bug，或者根据维护规模或性质本身就是一个大型事件。以下是基于特征的一些维护类型：

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

• 自适应维护 - 包括为保持软件产品与不断变化的技术和业务环境同步而应用的修改和更新。

• 完善性维护 - 包括为确保软件长期可用而进行的修改和更新。它包括新功能、新用户需求，以优化软件并提升其可靠性和性能。

• 预防性维护 - 包括为防止软件未来问题而进行的修改和更新。它旨在处理当前不显著但未来可能导致严重问题的问题。

维护成本

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

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

影响维护成本的现实世界因素

• 任何软件的标准寿命通常被认为为 10 到 15 年。
• 设计用于在低速机器上运行、内存和存储容量较小的旧软件，无法与现代硬件上新兴的增强型软件竞争。
• 随着技术进步，维护旧软件的成本会变得越来越高。
• 大多数维护工程师是新手，使用试错方法来解决问题。
• 经常进行的更改容易破坏软件的原始结构，从而使后续更改变得困难。
• 更改往往未被记录，这可能在未来导致更多冲突。

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

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

维护活动

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

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

• 识别与跟踪 - 它涉及与识别修改或维护需求相关的活动。这些需求由用户生成，或者系统可能通过日志或错误消息自行报告。在此，维护类型也会被分类。

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

• 设计 - 根据上一阶段设定的需求规范，设计需要替换或修改的新模块。为验证和确认创建测试用例。

• 实施 - 使用设计步骤中创建的结构化设计对新模块进行编码。每位程序员都应并行进行单元测试。

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

• 验收测试 - 在系统内部测试后，使用用户的帮助进行验收测试。如果此时用户投诉某些问题，则会处理这些问题或记录下来在下一次迭代中解决。

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

  如有需要，还提供培训设施，以及用户手册的硬拷贝。

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

软件重构工程

当我们需要更新软件以使其适应当前市场，同时不影响其功能时，这被称为软件重构工程。这是一个彻底的过程，其中软件的设计被更改，程序被重写。

遗留软件无法跟上市场上最新的技术。随着硬件变得过时，软件的更新变得棘手。即使软件随着时间变老，其功能也不会。

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

除此之外，有时程序员注意到软件的某些部分需要比其他部分更多的维护，它们也需要重构工程。

重构工程过程

• 决定重构什么。是整个软件还是其一部分？
• 执行逆向工程，以获取现有软件的规范。
• 重构程序，如果需要。例如，将面向函数的程序更改为面向对象的程序。
• 按需重构数据。
• 应用正向工程概念，以获得重构后的软件。

软件重构工程中有几个重要术语

逆向工程

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

现有系统是之前实现的某种设计，我们对其一无所知。设计人员通过查看代码进行逆向工程，试图获取设计。手中有了设计，他们再推导出规范。这样，从代码逆向到系统规范。

程序重构

它是重构和重建现有软件的过程。它涉及重新排列源代码，要么在相同的编程语言中，要么从一种编程语言转换到另一种。重构可以包括源代码重构和数据重构，或两者兼有。

重构不会影响软件的功能，但会提升可靠性和可维护性。那些经常导致错误的程序组件可以通过重构进行更改或更新。

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

正向工程

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

正向工程与软件工程过程相同，唯一的区别是它总是在逆向工程之后进行。

组件可重用性

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

示例

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

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

在 OOP 中，设计的对象非常特定于其关注点，因此被用于其他软件的机会较少。

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

有一个全新的领域，基于软件组件的重用，被称为 Component Based Software Engineering (CBSE)。

重用可以在各种级别进行

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

• Component level - 使用应用程序的子系统。

• Modules level - 重用功能模块。

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

重用过程

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

• Requirement Specification - 指定功能性和非功能性需求，软件产品必须遵守这些需求，可借助现有系统、用户输入或两者结合。

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

• Specify Components - 通过研究软件设计，设计师将整个系统分解为更小的组件或子系统。一个完整的软件设计转变为大量组件协同工作的集合。

• Search Suitable Components - 设计师参考软件组件仓库，根据功能性和预期软件需求搜索匹配的组件。

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