标签：软件产品 SWEBOK 软件维护 修改 软件工程 软件 维护 活动

软件维护（SOFTWARE MAINTENANCE）

软件开发工作的结果是交付满足用户需求的软件产品。因此，软件产品必须改变或发展。一旦投入使用，缺陷就会被发现，操作环境会发生变化，新的用户需求就会浮出水面。生命周期的维护阶段开始于保修期或实施后支持交付之后，但维护活动发生的时间要早得多。

软件维护是软件生命周期的一个组成部分。然而，它并没有得到与其他阶段同等程度的关注。从历史上看，在大多数组织中，软件开发比软件维护更受关注。这一点现在正在发生变化，因为各组织正努力通过尽可能长时间地保持软件运行来最大限度地利用其软件开发投资。开源范例进一步关注了维护由他人开发的软件构件的问题。

在本指南中，软件维护是指为软件提供经济高效的支持所需的全部活动。活动在交付前阶段和交付后阶段进行。交付前活动包括交付后操作的规划、可维护性和过渡活动的后勤确定[1*，c6s9]。交付后的活动包括软件修改、培训和操作或与服务台的接口。

软件维护知识领域（KA）与软件工程的所有其他方面相关。因此，本KA描述与指南中的所有其他软件工程KA相关联。

1. 软件维护的基本原理

第一节介绍了构成理解软件维护的角色和范围的基础的概念和术语。这些主题提供了定义并强调了为什么需要维护。软件维护的类别对于理解其基本含义至关重要。

1.1.定义和术语

软件维护的目的在国际软件维护标准ISO/IEC/IEEE 14764[1*]中定义。在软件工程的背景下，软件维护本质上是许多技术过程之一。

软件维护的目的是在保持软件完整性的同时对现有软件进行修改。国际标准还规定在软件最终交付之前进行一些维护活动（交付前活动）的重要性。值得注意的是，IEEE14764强调了交付前维护计划的重要性。

1.2.维护的性质

软件维护支持软件产品的整个生命周期（从开发到运行）。修改请求被记录和跟踪，提议的变更的影响被确定，代码和其他软件工件被修改，测试被执行，新版本的软件产品被发布。此外，还向用户提供培训和日常支持。术语维护者定义为执行维护活动的组织。在本KA中，术语有时指执行这些活动的个人，将他们与开发人员进行对比。

IEEE14764将软件维护的主要活动定义为过程实现、问题和修改分析、修改实现、维护评审/验收、迁移和退役。这些活动将在第3.2节“维护活动”中讨论。

维护人员可以从开发人员的软件知识中学习。与开发人员的联系和维护人员的早期参与有助于减少总体维护工作。在某些情况下，无法联系到最初的开发人员，或者已经转移到其他任务，这给维护人员带来了额外的挑战。维护必须从开发中获取软件工件（例如，代码或文档）并立即支持它们，然后在软件生命周期中逐步演化/维护它们。

1.3.必要的维护

维护是必要的，以确保软件继续满足用户需求。维护适用于使用任何软件生命周期模型开发的软件（(例如，螺旋或线性开发）。
由于纠正性和非纠正性的软件措施而导致的软件产品变更。必须进行维护，以便

• 纠正故障；
• 改进设计；
• 实施增强功能；
• 与其他软件的接口；
• 调整程序，以便使用不同的硬件、软件、系统功能和电信设施；
• 移植遗留软件；以及
• 淘汰软件。

五个关键特征构成了维护人员的活动：

• 保持对软件日常功能的控制；
• 保持对软件修改的控制；
• 完善现有职能；
• 识别安全威胁并修复安全漏洞；以及
• 防止软件性能降低到不可接受的水平。

1.4. 大部分维护费用

维护消耗了软件生命周期中的大部分财务资源。对软件维护的一个普遍看法是，它仅仅是修复故障。然而，多年来的研究和调查表明，大多数，超过80%的软件维护被用于非纠正操作[2*，图4.1]。在管理报告中将增强和更正合并在一起会造成一些关于更正费用高的错误观念。了解软件维护的类别有助于理解软件维护成本的结构。此外，了解影响软件可维护性的因素有助于控制成本。一些环境因素及其与软件维护成本的关系包括:

• 操作环境指硬件和软件。
• 组织环境是指政策，竞争，流程，产品和人员。

1.5. 软件进化

从进化的角度来看，软件维护最早是在20世纪60年代末提出的。在二十年的时间里，研究导致了八条进化定律的形成。主要的发现包括一个建议，即维护是进化的发展，并且维护决策是通过理解软件随时间的推移发生的变化来辅助的。有些人说维护就是持续的开发，除非有额外的输入（或约束）换句话说，现有的大型软件永远不是完整的，而是继续发展的；随着它的发展，它变得更加复杂，除非采取某种措施来降低这种复杂性。

1.6. 维护类别

定义了三类（类型）维护:纠正性，适应性和完善性[2*，c4s3]。IEEE 14764包括第四类:预防性。

• 纠正性维护:软件产品交付后进行的反应性修改（或修理），以纠正发现的问题。包括在这一类别中的是紧急维护，它是为在纠正性维护之前暂时保持软件产品运行而执行的未计划的修改。
• 适应性维护:软件产品交付后进行的修改，以保持软件产品在变化或不断变化的环境中可用。例如，操作系统可能升级，软件可能需要进行一些更改。
• 完善维护:软件产品交付后的修改，为用户提供增强功能，改进程序文档，重新编码，以提高软件性能，可维护性或其他软件属性。
• 预防性维护:在软件产品交付后对其进行修改，以便在软件产品中的潜在故障变成操作故障之前发现并纠正这些故障。

IEEE 14764将适应性维护和完善性维护分类为维护增强。它还将纠正性和预防性维护类别归为纠正类别，如表5.1所示。

2. 软件维护中的关键问题

必须处理若干关键问题，以确保软件的有效维护。软件维护为软件工程师提供了独特的技术和管理挑战，例如，试图在包含大量代码行的软件中找到一个错误，这些代码行是由另一个软件工程师开发的。同样，与软件开发人员争夺资源也是一场不断的争夺战。为未来的发行版进行规划，通常包括在为当前发行版发送紧急补丁的同时为下一个发行版编写代码，这也是一个挑战。以下部分介绍了一些与软件维护相关的技术和管理问题。它们按下列专题标题分类:

• 技术问题，
• 管理问题，
• 成本估算，以及
• 测量。

2.1. 技术问题

2.1.1. 有限的理解

有限理解是指一个软件工程师能够多快地理解在他或她没有开发的软件中在哪里进行更改或修正。研究表明，大约一半的维护工作都用于理解要修改的软件。因此，软件理解的主题是软件工程师非常感兴趣的。在源代码中，理解在面向文本的表示中更加困难，例如，如果更改没有被记录下来，如果开发人员无法解释它，那么通常很难通过其发行版/版本来跟踪软件的演变，这是经常发生的情况。因此，软件工程师最初可能对软件的理解有限；要纠正这种情况，还有很多工作要做。

2.1.2. 测试

就时间和金钱而言，在一个主要软件上重复全面测试的成本是巨大的。为了确保请求的问题报告有效，维护人员应该通过运行适当的测试来复制或验证问题。回归测试（对软件或组件进行有选择的重新测试，以验证修改没有造成意想不到的影响）是维护中一个重要的测试概念。此外，找时间进行测试通常很困难。当维护团队的不同成员同时处理不同的问题时协调测试仍然是一个挑战。当软件执行关键功能时，可能很难将其脱机进行测试。测试不能在生产系统中最有意义的地方执行。软件测试KA在其关于回归测试的子主题中提供了关于这个问题的额外信息和参考。

2.1.3. 影响分析

影响分析描述了如何对现有软件中的更改进行成本效益高的完整影响分析。维护人员必须对软件的结构和内容有深入的了解。他们使用这些知识来执行影响分析，该分析识别受软件变更请求影响的所有系统和软件产品，并对完成变更所需的资源进行估计。此外，确定进行更改的风险。变更请求，有时称为修改请求(MR)，通常称为问题报告(PR)，必须首先进行分析并转换为软件术语。影响分析是在变更请求进入软件配置管理流程后执行的。IEEE 14764规定了影响分析任务:

• 分析MRS/PRS；
• 重复或核实问题；
• 制定实施修改的备选方案；
• 记录MR/PR，结果和执行选项；
• 获得所选修改选项的批准。

问题的严重程度通常用来决定如何和何时修复问题。然后，软件工程师识别受影响的组件。本报告提供了几种可能的解决办法，并就最佳行动方案提出了建议。
考虑到可维护性而设计的软件极大地方便了影响分析。更多信息可以在软件配置管理KA中找到。

2.1.4. 可维护性

IEEE 14764[1*，c3s4]将可维护性定义为要修改的软件产品的能力。修改可以包括修正，改进或使软件适应环境的变化以及需求和功能规范的变化。
可维护性作为一个主要的软件质量特征，应该在软件开发活动中加以规定，审查和控制，以降低维护成本。成功完成后，软件的可维护性将得到提高。可维护性通常很难实现，因为子特性在软件开发过程中通常不是一个重要的关注点。开发人员通常更专注于许多其他活动，并且经常倾向于忽视维护人员的需求。这反过来可能，而且经常会导致缺乏软件文档和测试环境，这是程序理解和后续影响分析困难的主要原因。系统和成熟的过程，技术和工具的存在有助于增强软件的可维护性。

2.2. 管理问题

2.2.1.与组织目标保持一致

组织目标描述了如何论证软件维护活动的投资回报。最初的软件开发通常是基于项目的，具有定义的时间范围和预算。主要强调的是按时，在预算范围内交付一个满足用户需求的产品。相反，软件维护的目标往往是尽可能地延长软件的寿命。此外，它可能是由满足用户对软件更新和增强的需求的需要所驱动的。在这两种情况下，投资回报都不太明确，因此高级管理层往往认为，一项重大活动消耗大量资源，却没有给本组织带来明确的，可量化的效益。

2.2.2.人员配置

人员配备是指如何吸引和留住软件维护人员。维修工作通常不被认为是有魅力的工作。因此，软件维护人员经常被视为二等公民，士气因此受到打击。

2.2.3. 流程

软件生命周期过程是人们用来开发和维护软件及其相关产品的一组活动，方法，实践和转换。在过程级别上，软件维护活动与软件开发有许多共同之处（例如，软件配置管理在两者中都是至关重要的活动）。维护还需要几个在软件开发中没有的活动（详见关于独特活动的3.2节）。这些活动对管理提出了挑战。

2.2.4.维护的组织方面

组织方面描述了如何确定哪个组织和/或职能将负责软件的维护。开发软件的团队不一定被指派在软件运行后维护软件。
在决定软件维护功能将位于何处时，软件工程组织可以，例如，与原始开发人员呆在一起，或者去找一个永久性的维护特定团队（或维护人员）。拥有一个永久的维护团队有很多好处:

• 允许专业化；
• 建立通信渠道；
• 促进一种无我的大学氛围；
• 减少对个人的依赖；
• 允许定期审计检查。

由于每种选择都有许多利弊，因此应逐案作出决定。重要的是将维护责任委托或分配给一个单独的小组或个人，而不管组织的结构如何。

2.2.5.外包

外包和离岸外包软件维护已经成为一个主要行业。组织正在外包整个软件组合，包括软件维护。更多的情况是，外包选项被选择用于任务不那么关键的软件，因为组织不愿意失去对其核心业务中使用的软件的控制。外包商面临的主要挑战之一是确定所需维护服务的范围，服务级协议的条款以及合同细节。外包商将需要投资于维护基础设施，远程站点的服务台应配备讲母语的工作人员。外包需要大量的初始投资和维护过程的设置，这将需要自动化。

2.3.维护费用估算

为了解决估计软件维护成本的问题，软件工程师必须了解以上讨论的不同类型的软件维护。出于计划的目的，成本估算是软件维护计划的一个重要方面。

2.3.1.成本估算

第2.1.3节描述了影响分析如何识别受软件变更请求影响的所有系统和软件产品，并对完成该变更所需的资源进行估计。
维护费用估计受到许多技术和非技术因素的影响。IEEE 14764指出，估计软件维护资源的两种最流行的方法是使用参数模型和使用经验[1*，C7S4.1]。也可以使用这两种方法的组合。

2.3.2.参数模型

参数化成本建模（数学模型）已被应用于软件维护。重要的是，为了使用和校准数学模型，需要过去维修的历史数据。成本动因属性影响估计。

2.3.3. 经验

经验，以专家判断的形式，经常被用来估计维护努力。显然，维护评估的最佳方法是结合历史数据和经验。然后，作为测量程序的结果，应提供进行修改的成本（以人数和时间量计）。

2.4.软件维护度量

与软件维护相关的实体，其属性可以接受度量，包括过程，资源和产品[2*，C12S3.1]。
有几种软件度量可以从软件的属性，维护过程和人员中得到，包括大小，复杂性，质量，可理解性，可维护性和工作量。软件的复杂性度量也可以使用可用的商业工具获得。这些测量构成了维护人员测量计划的良好起点。在软件工程过程KA中还讨论了软件过程和产品度量。在软件工程管理KA中描述了一个软件度量程序的主题。

2.4.1. 具体措施

维护人员必须根据特定组织自己的环境确定哪些度量值适合该组织。软件质量模型建议了特定于软件维护的度量。可维护性子特性的度量包括以下[4*，p.60]:

• 可分析性:衡量维护人员在试图诊断缺陷或故障原因或确定需要修改的部件时所花费的努力或资源。
• 可变性:与实现指定修改相关的维护人员工作的度量。
• 稳定性:衡量软件的意外行为，包括测试期间遇到的行为。
• 可测试性:维护人员和用户在测试修改后的软件方面所作努力的量度。
• 维护人员使用的其他措施包括
• 软件的大小，
• 软件的复杂性，
• 可理解性，以及
• 可维护性。

按类别为不同的应用程序提供软件维护工作，为用户及其组织提供业务信息。它还可以在组织内部比较软件维护配置文件。

3.维护工艺

除了IEEE 14764中描述的标准软件工程过程和活动之外，还有许多活动是维护人员所独有的。

3.1.维护过程

如IEEE 14764所述，维护过程提供所需的活动和这些活动的详细输入/输出。IEEE 14764的维护过程活动如图5.2所示。软件维护活动包括

• 实施过程，(process implementation)
• 问题和修改分析，(problem and modification analysis)
• 修改实施，(modification implementation)
• 维护审查/验收，(maintenance review/acceptance)
• 迁移(migration)
• 软件退役。(software retirement)
  
  其他维护流程模型包括:
• 快速修复，
• 螺旋模型，
• 奥斯本模型，(Osborne’s)
• 迭代增强，以及
• 面向重用。

最近，促进轻流程的敏捷方法学也适用于维护。这一要求产生于对维修服务快速周转的不断增长的需求。对软件维护过程的改进由专门的软件维护能力成熟度模型支持（见[6]和[7]，在进一步的阅读部分中有简要的注释）。

3.2.维护活动

维护过程包含修改现有软件产品同时保持其完整性所必需的活动和任务。这些活动和任务由维护人员负责。如前所述，许多维护活动与软件开发活动相似。维护人员执行分析，设计，编码，测试和文档。他们必须在其活动中跟踪需求，就像在开发中所做的那样，并在基线变化时更新文档。IEEE 14764建议，当维护人员使用开发过程时，必须对其进行裁剪，以满足特定的需求[1*，C5S3.2.2]。但是，对于软件维护来说，有些活动涉及到软件维护所特有的过程。

3.2.1.独特活动

有许多过程，活动和实践是软件维护所特有的:

• 程序理解:获得软件产品的功能和各部分如何协同工作的一般知识所需的活动。
• 过渡:一个受控制和协调的活动序列，在此过程中，软件逐渐从开发人员转移到维护人员。
• 修改请求接受/拒绝:修改请求超出一定规模/工作量/复杂度的工作可能会被维护人员拒绝，并被重新分配给开发人员。
• 维修服务台:一个最终用户和维修协调支助功能，触发对修改请求的评估，优先排序和成本计算。
• 影响分析:一种查明受潜在变化影响的领域的技术；
• 维护服务级协议以及维护许可证和合同:描述服务和质量目标的合同协议。

3.2.2.支持活动

维护人员还可以执行支持活动，例如文档编制，软件配置管理，验证和验证，问题解决，软件质量保证，评审和审核。另一项重要的支助活动包括培训维护人员和用户。

3.2.3.维护计划活动

软件维护的一个重要活动是计划，维护人员必须解决与许多计划观点相关联的问题，包括

• 业务规划（组织一级），
• 维护规划（过渡级别），
• 版本/版本规划（软件级），以及
• 单个软件更改请求计划（请求级别）。

在个人请求层面，在影响分析期间进行规划（见第2.1.3节，影响分析）。版本/版本规划活动要求维护人员:

• 收集个别请求的可用日期，
• 与用户商定后续版本/版本的内容，
• 查明潜在的冲突并制定替代办法，
• 评估特定释放的风险，并在出现问题时制定一个退出计划，以及
• 通知所有利益攸关方。

软件开发项目通常会持续几个月到几年，而维护阶段通常会持续很多年。对资源进行估计是维护计划的一个关键要素。软件维护计划应该从开发一个新的软件产品的决定开始，并且应该考虑质量目标。应制定概念文件，然后制定维护计划。每个软件产品的维护概念需要在计划中记录[1*，c7s2]，并应解决

• 软件维护的范围，
• 调整软件维护程序，
• 软件维护组织的标识，以及
• 软件维护成本估算。

下一步是制定相应的软件维护计划。此计划应在软件开发期间准备，并应规定用户将如何请求软件修改或报告问题。软件维护计划在IEEE14764中有涉及。它为维护计划提供指导。最后，在最高层，维护组织将必须像组织的所有其他部门一样进行业务规划活动（预算，财务和人力资源）。管理在软件工程的相关学科一章中讨论。

3.2.4.软件配置管理

IEEE 14764将软件配置管理描述为维护过程的关键元素。软件配置管理程序应规定对识别，授权，实施和发布软件产品所需的每个步骤进行验证，确认和审核。
仅仅跟踪修改请求或问题报告是不够的。必须控制软件产品和对其所做的任何更改。这种控制是通过实施和实施经批准的软件配置管理(SCM)过程来建立的。软件配置管理 KA提供了SCM的详细信息，并讨论了提交，评估和批准软件变更请求的过程。用于软件维护的SCM与用于软件开发的SCM在操作软件上必须控制的小变更的数量上有所不同。SCM过程是通过开发并遵循软件配置管理计划和操作程序来实现的。维护人员参与配置控制板，以确定下一个版本/版本的内容。

3.2.5.软件质量

仅仅希望通过软件的维护来提高质量是不够的。维护人员应该有一个软件质量计划。必须对其进行计划，必须实施过程以支持维护过程。软件质量保证（SQA，V&V，评审和审核）的活动和技术必须与所有其他过程一致地选择，以达到所需的质量水平。还建议维护人员修改软件开发过程，技术和可交付成果（例如，测试文档）以及测试结果。更多的细节可以在软件质量KA中找到。

4.维护技术

本主题介绍了软件维护中使用的一些公认的技术。

4.1.程序理解

程序员花费相当多的时间来阅读和理解程序，以便实现更改。代码浏览器是程序理解的关键工具，用于组织和呈现源代码。清晰和简洁的文档也有助于程序的理解。

4.2.再造

再造工程被定义为检查和更改软件以以新的形式重新构建它，并包括新形式的后续实现。通常不是为了提高可维护性，而是为了替换老化的遗留软件。重构是一种重组技术，目的是在不改变程序行为的情况下重组程序。它寻求改进程序结构及其可维护性。重构技术可以在较小的更改期间使用。

4.3.逆向工程

逆向工程是分析软件以识别软件组件及其相互关系并以另一种形式或更高抽象层次创建软件表示的过程。逆向工程是被动的；它不会改变软件或产生新的软件。逆向工程努力从源代码中生成调用图和控制流图。逆向工程的一种类型是重新文档化。另一种类型是设计恢复。最后，数据反向工程（从物理数据库中恢复逻辑模式）在过去几年中变得越来越重要。工具是反向工程和相关任务（如重新文档和设计恢复）的关键。

4.4.迁移

在软件的生命周期中，它可能必须被修改以在不同的环境中运行。为了将其迁移到新的环境中，维护人员需要确定完成迁移所需的操作，然后在迁移计划中开发和记录实施迁移所需的步骤，该计划涵盖迁移需求，迁移工具，产品和数据的转换，执行，验证和支持。
迁移软件还需要许多额外的活动，例如
•意向通知:说明不再支持旧环境的原因，然后说明新环境及其可用日期；
•并行操作:提供新旧环境，使用户顺利过渡到新环境；
•完成通知:计划的迁移完成后，向所有有关方面发出通知；
•作业后审查:评估并行作业和适应新环境的影响；
•数据存档:存储旧软件数据。

4.5.退休

一旦软件达到其使用寿命的终点，它就必须退役。应进行分析，以协助作出退休决定。这一分析应该包含在退休计划中，其中包括退休要求，影响，替换，时间表和努力。还可包括数据存档副本的可访问性。退役软件需要进行许多类似于迁移的活动。

5.软件维护工具

本主题包括在修改现有软件的软件维护中特别重要的工具。关于程序理解的示例包括

• 程序切片器，仅选择受更改影响的程序部分；
• 静态分析器，允许对节目内容进行一般查看和摘要；
• 动态分析器，允许维护人员跟踪程序的执行路径；
• 数据流分析器，使维护人员能够跟踪程序的所有可能数据流；
• 产生方案组成部分索引的交叉参照器；和
• 依赖性分析器，帮助维护人员分析和理解程序各组成部分之间的相互关系。

反向工程工具通过从现有产品向后工作来帮助该过程，以创建工件，例如规范和设计描述，然后可以将这些工件转换为从旧产品生成新产品。维护人员还使用软件测试，软件配置管理，软件文档和软件度量工具。

标签：软件产品,SWEBOK,软件维护,修改,软件工程,软件,维护,活动
来源： https://blog.csdn.net/imlichao/article/details/112876730

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。