软件工程入门教程 软件工程 维护

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

• 市场状况 - 政策随着时间的推移而变化，例如税收和新引入的约束，例如如何维护账本，可能会引发修改的需要。
• 客户要求 - 随着时间的推移，客户可能会要求软件中的新特性或功能。
• 主机修改 - 如果目标主机中的任何硬件或平台（如操作系统）发生变化，则需要更改软件以保持适应性。
• 组织变更 - 如果客户端有任何业务层面的变化，如机构实力下降、收购另一家公司、机构涉足新业务等，都可能需要对原有软件进行修改。

维修类型

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

• 修复性维护 - 包括为纠正或修复问题而进行的修改和更新，这些问题要么由用户发现，要么由用户错误报告得出。
• 适应性维护 - 包括用于使软件产品保持最新并且适应不断变化的技术和商业环境世界的修改和更新。
• 完善的维护 - 包括为软件长时间可用而进行的修改和更新。它包括新功能、改进软件和提高其可靠性和性能的新用户要求。
• 预防性维护 - 包括为防止软件未来出现问题而进行的修改和更新。它旨在解决目前不重要但将来可能会导致严重问题的问题。

维护成本

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

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

影响维护成本的现实因素

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

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

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

维护活动

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

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

• 识别与跟踪 - 涉及与识别修改或维修要求相关的活动。它是由用户生成的，或系统可能通过日志或错误信息自行报告。在这里，维护类型也进行了分类。
• 分析 - 分析修改对系统的影响，包括安全和安保影响。如果可能的影响很严重，则寻找可替代解决方案。然后将一组所需要的修改具体化为需求规范。对修改/维护的成本进行了分析，得出估算结论。
• 设计 - 需要更改或修改的新模块根据前一阶段设定的需求规范进行设计。为验证和验证而创建测试用例。
• 实施 - 新模块在设计阶段创建的结构化设计的帮助下进行编码。每个程序员应该并行进行单元测试。
• 系统测试 - 在新创建的模块之间进行集成测试。在新的模块和系统之间也进行集成测试。最后，按照回归测试程序对系统进行整体测试。
• 验收测试 - 在对系统进行内部测试后，在用户的帮助下对其进行验收测试。如果处于这种状态下，用户会抱怨他们在下一次迭代中解决或注意到要解决的一些问题。
• 交付 - 验收测试后，系统通过小型更新包或新安装的系统部署到整个组织。最终测试在软件交付后的客户端进行。
  除了用户手册的硬拷贝外，如果需要，还提供培训设施。
• 维护管理 - 配置管理是系统维护的重要组成部分。它是借助版本控制工具来控制版本，半版本或补丁管理。

软件再工程

当我们需要更新软件以保证它适应当前的市场，而不会影响其功能，我们称之为软件再工程。这是一个全面的过程，软件的设计会变更， 程序会被重新写入。

传统的软件无法使用市场上现有的最新技术进行调整。随着硬件的过时，软件更新成为一个头疼的问题。即使软件随着时间的推移而衰老，但是它的功能不会变老。

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

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

重组流程

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

还有在软件再工程中很少用到，但是很重要的几个术语：

逆向工程

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

现有系统是以前设计的实现，对此我们一无所知。然后，设计师通过查看代码进行逆向工程，并尝试获得设计。有了设计，他们就会尝试总结出规范。因此，从代码到系统规范的顺序是相反的。

项目重组

这是一个重新构建现有软件的过程。这一切都是关于重新编排源代码，无论是用相同的编程语言，还是从一个编程语言到另一种编程语言。重组可以有源代码和数据重组，或两者兼而有之.

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

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

正向工程

正向工程是通过逆向工程从手头的规范中获取所需软件的过程。它假设过去已经完成了一些软件工程。

正向工程与软件工程过程是一样的，只有一点区别就是，它总是在逆向工程之后执行。

组件的可重用性

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

示例

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

组件具有较高的功能内聚和较低的耦合率，也就是说，它们相互独立，可以不依赖于其他模块的情况下执行任务。

在面向对象（OOP）中，设计的对象非常特定于它们所关注的问题，并很少有机会在其它软件中使用。

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

有一种全新的垂直结构，这是基于软件组件的重用，被称为基于组件的软件工程（CBSE)。

可以在各个层次进行重用：

• 应用层 - 将整个应用程序用作新软件的子系统.
• 组件级 - 使用应用程序子系统的位置。
• 模块级 - 重复使用的功能模块的位置。

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

再利用过程

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

• 需求规范 - 功能性和非功能性需求被指定，软件产品必须符合其中，与现有的系统中，用户输入或两者的帮助.
• 设计 - 这也是一种标准的SDLC过程步骤，其中要求在软件中用语的定义。系统的基本架构作为一个整体，其子系统中创建的.
• 指定组件 - 通过对软件的设计，设计师隔离整个系统分成较小的组件或子系统。一个完整的软件设计，变成了一组组巨大的协同工作的集合.
• 搜索合适的组件 - 软件构件库是由设计师称为搜索匹配元件，功能的基础上，拟软件要求上.
• 集成组件 - 所有匹配组件打包在一起，塑造他们作为完整的软件.