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

• 市场状况-随时间变化的政策(例如税收和新引入的限制条件，如如何维持簿记)可能会引发对修改的需求。

• 客户要求-随着时间的流逝，客户可能会要求软件提供新功能。

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

• 组织变更-如果客户端的业务水平发生任何变更，例如组织实力下降，收购另一家公司，组织涉足新业务，则可能需要对原始软件进行修改。

维护类型

在软件生命周期中，维护类型可能会因其性质而异。它可能只是例行维护任务，因为某些用户发现了一些错误，或者它本身可能是一个大事件，根据维护规模或性质而定。以下是根据其特点进行的某些类型的维护：

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

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

• 完善的维护-包括所做的修改和更新，以确保软件长期可用。它包括新功能，完善软件以及提高可靠性和性能的新用户要求。

• 预防性维护-包括修改和更新，以防止软件将来出现问题。它的目的是解决目前尚不重要的问题，但将来可能会引起严重的问题。

维修费用

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

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

影响维护成本的现实因素

• 任何软件的标准寿命都被认为是10至15年。
• 本来可以在内存和存储容量较少的慢速计算机上运行的较旧的软件也无法与现代硬件上的新增强软件保持挑战。
• 随着技术的进步，维护旧软件的成本变得很高。
• 大多数维护工程师都是新手，并且使用试错法来纠正问题。
• 通常，所做的更改很容易损害软件的原始结构，从而使后续更改变得困难。
• 更改通常没有记录在案，将来可能会引起更多冲突。

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

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

维修活动

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

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

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

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

• 设计-根据前一阶段设定的需求规格设计需要更换或修改的新模块。创建测试用例以进行验证和验证。

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

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

• 验收测试-在内部测试了系统之后，在用户的帮助下测试了验收。如果处于此状态，则用户抱怨某些问题，这些问题将在下一次迭代中得到解决或记录。

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

  除用户手册的印刷版外，如果需要还提供培训工具。

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

软件再造

当我们需要更新软件以使其在不影响其功能的情况下保持当前市场时，称为软件重新设计。这是一个彻底的过程，需要更改软件的设计并重新编写程序。

旧版软件无法与市场上的最新技术保持一致。随着硬件的过时，软件的更新变得令人头疼。即使软件随着时间的流逝而老化，其功能也不会。

例如，最初Unix是用汇编语言开发的。当C语言问世时，Unix用C重新设计，因为用汇编语言工作很困难。

除此之外，有时程序员会注意到软件的很少部分需要比其他部分更多的维护，并且他们还需要重新设计。

再造过程

• 决定要重新设计的内容。它是整个软件还是一部分?
• 执行逆向工程，以获取现有软件的规格。
• 如果需要，重组程序。例如，将面向功能的程序更改为面向对象的程序。
• 根据需要重组数据。
• 应用前瞻性工程概念以获取重新设计的软件。

软件再造中很少使用重要术语

逆向工程

这是通过全面分析，了解现有系统来达到系统规格的过程。这个过程可以看作是反向SDLC模型，即我们试图通过分析较低的抽象级别来获得较高的抽象级别。

现有系统是以前实现的设计，对此我们一无所知。然后，设计师通过查看代码进行逆向工程并尝试获得设计。他们掌握了设计之后，便会尝试得出规格说明。因此，从代码转向系统规范。

计划重组

这是重新构造和重新构造现有软件的过程。一切都是关于以相同的编程语言或从一种编程语言到另一种编程语言重新排列源代码。重组可以具有源代码重组和数据重组，也可以同时具有两者。

重组不会影响软件的功能，但会提高可靠性和可维护性。经常导致错误的程序组件可以更改，也可以通过重组来更新。

可以通过重组来消除过时硬件平台上软件的可靠性。

正向工程

正向工程是从手头的规格中获得所需软件的过程，这些规格是通过反向工程而降低的。假定过去已经完成了一些软件工程。

正向工程与软件工程过程相同，只有一个区别–它总是在反向工程之后执行。

组件可重用性

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

例

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

组件具有较高的功能凝聚力和较低的耦合率，即，它们独立工作并且可以执行任务而无需依赖其他模块。

在OOP中，对象的设计非常关注他们的关注，并且很少有机会在其他某些软件中使用。

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

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

可以在各个级别重复使用

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

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

• 模块级别-重复使用功能模块的位置。

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

重用过程

可以采用两种方法：通过保持需求相同并调整组件，或者通过保持组件相同并修改需求。

• 需求规范-在现有系统的帮助下，指定了软件产品必须遵守的功能要求和非功能要求，用户输入或两者。

• 设计-这也是SDLC的标准处理步骤，其中要求以软件术语定义。创建了系统整体及其子系统的基本体系结构。

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

• 搜索合适的组件-设计人员根据功能和预期的软件需求，将软件组件存储库引向其搜索匹配的组件。

• 合并组件-将所有匹配的组件打包在一起，以将它们塑造为完整的软件。