软件维护概述 – 软件工程教程

上一章软件工程教程请查看：软件测试概述

软件维护现在已经成为SDLC中被广泛接受的一部分，它代表在软件产品交付之后所做的所有修改和更新，需要修改的理由有很多，其中一些理由简述如下：

• 市场状况-政策，随着时间的变化，如税收和新引入的约束，如如何保持簿记，可能需要修改。
• 客户需求——随着时间的推移，客户可能会要求软件的新特性或功能。
• 主机修改——如果目标主机的任何硬件和平台(如操作系统)发生变化，则需要对软件进行修改以保持适应性。
• 组织变更——如果在客户端有任何业务级别的变更，如组织实力的削弱、收购另一家公司、组织冒险进入新业务，需要修改的原始软件可能会出现。

维护的类型

在软件生命周期中，维护类型可能根据其性质而有所不同。它可能只是一些用户发现的一些bug的例行维护任务，也可能是基于维护规模或性质的大型事件。以下是一些基于其特点的维修类型：

• 纠正性维护——这包括为了纠正或修复问题而进行的修改和更新，这些问题可能是由用户发现的，也可能是由用户错误报告总结的。
• 自适应维护——这包括对软件产品进行修改和更新，以使软件产品保持最新并适应不断变化的技术和业务环境。
• 完美的维护-这包括修改和更新，以保持软件在很长一段时间内可用。它包括新的功能，新的用户需求，以改进软件和提高其可靠性和性能。
• 预防性维护——包括修改和更新，以防止软件将来出现问题。它的目的是解决问题，这些问题目前并不重要，但将来可能会引起严重的问题。

维护成本

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

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

影响维护成本的现实因素

• 任何软件的标准年龄都被认为是10到15岁。
• 旧的软件本来是要在速度较慢、内存和存储容量更小的机器上运行的，但它们无法与现代硬件上新出现的增强软件相抗衡。
• 随着技术的进步，维护旧软件的成本越来越高。
• 大多数维修工程师都是新手，他们用试错法来解决问题。
• 通常，所做的更改很容易破坏软件的原始结构，使得后续的更改非常困难。
• 更改常常没有文档记录，这可能会在将来导致更多的冲突。

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

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

维护活动

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

这些活动与下列各阶段密切相关：

• 标识和跟踪——它涉及到与标识修改或维护需求相关的活动。它是由用户或系统本身通过日志或错误消息报告生成的。这里还对维护类型进行了分类。
• 分析—分析修改对系统的影响，包括安全性和安全方面的影响。如果可能的影响是严重的，寻找替代的解决方案。然后一组需要的修改被具体化为需求规格。分析了改造/维护的成本，并进行了估算。
• 设计-新的模块，需要更换或修改，根据前一阶段设定的需求规格进行设计。为验证和验证创建测试用例。
• 实现——在设计步骤中创建的结构化设计的帮助下，对新模块进行编码。每个程序员都应该并行地进行单元测试。
• 系统测试——在新创建的模块之间进行集成测试。新模块与系统之间也进行了集成测试。最后，系统作为一个整体进行测试，遵循回归测试程序。
• 验收测试——对系统进行内部测试后，在用户的帮助下进行验收测试。如果在这种状态下，用户抱怨一些他们在下一次迭代中要解决的问题。
• 交付-验收测试后，系统通过小的更新包或系统的新安装在整个组织中进行部署。在软件交付之后，在客户端进行最后的测试。

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

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

软件再工程

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

遗留软件不能一直与市场上可用的最新技术保持一致。当硬件变得过时时，软件的更新就成了一个头痛的问题。即使软件会随着时间的推移而老化，它的功能却不会。

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

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

再造流程

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

在软件重构中很少用到重要的术语

逆向工程

它是一个通过深入分析、理解现有系统来实现系统规范的过程。这个过程可以看作是逆向SDLC模型，即我们试图通过分析较低的抽象层次来获得更高的抽象层次。

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

重组计划

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

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

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

正向工程

前向工程是通过逆向工程的方法，从手头的说明书中获取所需软件的过程。它假设在过去已经完成了一些软件工程。

正向工程和软件工程过程是一样的，只有一个区别——它总是在逆向工程之后进行。

组件的可重用性

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

例子

网上使用的登录程序可以看作是组件，软件中的打印系统可以看作是软件的组件。

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

在面向对象编程中，对象的设计非常具体，很少有机会在其他软件中使用。

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

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

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

• 应用程序级别——将整个应用程序用作新软件的子系统。
• 组件级——这里使用应用程序的子系统。
• 模块级——重用功能模块的地方。

软件组件提供接口，可以用来建立不同组件之间的通信。

重用过程

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

• 需求规范——指定了功能需求和非功能需求，软件产品必须在现有系统、用户输入或两者的帮助下遵守这些需求。
• 设计——这也是一个标准的SDLC过程步骤，其中需求是根据软件术语定义的。建立了系统的基本体系结构及其子系统。
• 指定组件——通过研究软件设计，设计者将整个系统分成更小的组件或子系统。一个完整的软件设计变成了一个巨大的组件集合在一起工作。
• 搜索合适的组件——软件组件库由设计人员根据功能和预期的软件需求来搜索匹配的组件。
• 合并组件-所有匹配的组件打包在一起，形成完整的软件。