在软件产品被开发出来并交付用户使用之后，就进入了软件的运行维护阶段。这个阶段是软件生命周期的最后一个阶段，其基本任务是保证软件在一个相当长的时期(10年）能够正常运行。软件维护需要的工作量很大，平均说来，大型软件的维护成本高达开发成本的4倍左右。软件工程的主要目的之一就是要提高软件的可维护性，减少软件维护所需要的工作量，降低软件系统的总成本
软件维护的定义
软件维护就是在软件已经交付使用之后，为 了改正错误或满足新的需要而修改软件的过程。可以通过描述软件交付使用后可能进行的4项活动（改正性维护 适应性维护 完善性维护 预防性维护），具体地定义软件维护。
国外统计数据表明，完善性维护占全部维护活动的50~66%，改正性维护占17~21%，适应性维护占18~25%，其他维护活动只占4%左右
上述4类维护活动都必须应用于整个软件配置，维护软件文档和维护软件的可执行代码同样重要
改正性维护
因为软件测试不可能暴露出一个大型软件系统中所有潜藏的错误，所以必然会有第一项维护活动：
在任何大型程序的使用期间，用户必然会发现程序错误，并且把他们遇到的问题报告给维护人员。把诊断和改正错误的过程称为改正性维护。
适应性维护
适应性维护，是为了和变化了的环境适当地配合而进行的修改软件的活动，是既必要又经常的维护活动。
完善性维护
当一个软件系统顺利地运行时，常常出现第三项维护活动：在使用软件的过程中用户往往提出增加新功能 或修改已有功能的建议，还可能提出一般性的改进意见。 为了满足这类要求，需要进行完善性维护。这项维护活动通常占软件维护工作的大部分。
预防性维护
当为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件时，出现了第四项维护活动。这项维护活动通常称为预防性维护，目前这项维护活动相对比较少。
软件维护的特点
非结构化维护
如果软件配置的唯一成分是程序代码，那么维护活动从艰苦地评价程序代码开始，而且常常由于程序内部文档不足而使评价更困难，对于软件结构、全程数据结构、系统接口、性能和(或)设计约束等经常会产生误解，而且对程序代码所做的改动的后果也是难于估量的。
非结构化维护需要付出很大代价(浪费精力并且遭受挫折的打击)，这种维护方式是没有使用良好定义的方法学开发出来的软件的必然结果
结构化维护
如果有一个完整的软件配置存在，那么维护工作从评价设计文档开始，确定软件重要的结构、性能以及接口等特点；估量要求的改动将带来的影响，并且计划实施途径。然后：
首先，修改设计并且对所做的修改进行仔细复查。
然后，编写相应的源程序代码；
接下来，使用在测试说明书中包含的信息进行回归测试；
最后，把修改后的软件再次交付使用。
以上描述的事件构成结构化维护，它是在软件开发的早期应用软件工程方法学的结果。虽然有了软件的完整配置并不能保证维护中没有问题，但是确实能减少精力的浪费并且能提高维护的总体质量。
维护的代价高昂
因为可用的资源必须供维护任务使用，以致耽误甚至丧失了开发的良机，这是软件维护的一个无形的代价。其他无形的代价还有以下几个:
当看来合理的有关改错或修改的要求不能及时满足时将引起用户不满。
由于维护时的改动，在软件中引入了潜伏的错误，从而降低了软件的质量。
当必须把软件工程师调去从事维护工作时，将在开发过程中造成混乱
软件维护的最后一个代价是生产率的大幅度下降，这种情况在维护旧程序时常常遇到。
维护存在的问题
（1）理解别人写的程序通常非常困难，而且困难程度随着软件配置成分的减少而迅速增加。如果仅有程序代码没有说明文档，则会出现严重的问题。
（2） 需要维护的软件往往没有合格的文档，或者文档资料显著不足。认识到软件必须有文档仅仅是第一步，容易理解的并且和程序代码完全一致的文档才真正有价值。
（3） 当要求对软件进行维护时，不能指望由开发人员给人们仔细说明软件。由于维护阶段持续的时间很长，因此，当需要解释软件时，往往原来写程序的人已经不在附近了。
（4） 绝大多数软件在设计时没有考虑将来的修改。除非使用强调模块独立原理的设计方法学，否则修改软件既困难又容易发生差错。
（5） 软件维护不是一项吸引人的工作。形成这种观念很大程度上是因为维护工作经常遭受挫折。
上述种种问题在现有的没采用软件工程思想开发出来的软件中，都或多或少地存在着。不应该把一种科学的方法学看做万应灵药，但是，软件工程至少部分地解决了与维护有关的每一个问题
软件维护的过程
维护过程本质上是修改和压缩了的软件定义和开发过程， 而且事实上远在提出一项维护要求之前，与软件维护有关的工作已经开始了。 首先必须建立一个维护组织（维护管理员、熟悉该产品的系统管理员/技术人员、变化授权人），随后必须确定报告和评价的过程，而且必须为每个维护要求规定一个标准化的事件序列，此外，还应该建立一个适用于维护活动的记录保管过程， 并且规定复审标准
保护维护记录
1程序标识；2源语句数；3机器指令条数；4使用的程序设计语言；5程序安装的日期；6自从安装以来程序运行的次数；7自从安装以来程序失效的次数；8程序变动的层次和标识；9因程序变动而增加的源语句数；10因程序变动而删除的源语句数；11每个改动耗费的人时数；12程序改动的日期；13软件工程师的名字； 14维护要求表的标识；15维护类型；16维护开始和完成的日期； 17累计用于维护的人时数；18与完成的维护相联系的纯效益。
应该为每项维护工作都收集上述数据。可以利用这些数据构成一个维护数据库的基础
评价维护活动 ，可以从下述7个方面度量维护工作
(1) 每次程序运行平均失效的次数。 (2) 用于每一类维护活动的总人时数。 (3) 平均每个程序、每种语言、每种维护类型所做的程序变动数。 (4) 维护过程中增加或删除一个源语句平均花费的人时数。 (5) 维护每种语言平均花费的人时数。 (6) 一张维护要求表的平均周转时间。 (7) 不同维护类型所占的百分比
软件的可维护性
可以把软件的可维护性定性地定义为： 维护人员理解、改正、改动或改进这个软件的难易程度。提高可维护性是支配软件工程方法学所有步骤的关键目标！维护就是在软件交付使用后进行的修改，修改之前必须理解待修改的对象，修改之后应该进行必要的测试，以保证所做的修改是正确的。如果是改正性维护，还必须预先进行调试以确定错误的具体位置。因此，决定软件可维护性的因素主要有下述5个。 1. 可理解性 2. 可测试性 3. 可修改性 4. 可移植性 5. 可重用性
1. 可理解性
软件可理解性表现为外来读者理解软件的结构、功能、接口和内部处理过程的难易程度。
模块化（模块结构良好，高内聚，松/低耦合）、详细的设计文档、结构化设计、程序内部的文档和良好的高级程序设计语言等，都对提高软件的可理解性有重要贡献。
2. 可测试性
测试、诊断、调试的容易程度取决于软件容易理解的程度。
良好的文档
软件结构
可用的测试工具
调试工具
以前设计的测试过程
开发阶段用过的测试方案，以便维护人员进行回归测试
在设计阶段应该尽力把软件设计成容易测试和容易诊断的
对于程序模块来说，可以用程序复杂度来度量它的可测试性。模块的环形复杂度越大，可执行的路径就越多，因此， 全面测试它的难度就越高。
3. 可修改性
耦合、内聚、信息隐藏、局部化、控制域与作用域的关系等，都影响软件的可修改性。
4. 可移植性
软件可移植性指的是，把程序从一种计算环境（硬件配置和操作系统）转移到另一种计算环境的难易程度。把与硬件、操作系统以及其他外部设备有关的程序代码集中放到特定的程序模块中，可以把因环境变化而必须修改的程序局限在少数程序模块中，从而降低修改的难度。
5.可重用性
所谓重用（reuse）是指同一事物不做修改或稍加改动就在不同环境中多次重复使用。大量使用可重用的软件构件来开发软件，可以从下述两个方面提高软件的可维护性。
(1) 通常，可重用的软件构件在开发时都经过很严格的测试，可靠性比较高，且在每次重用过程中都会发现并清除一些错误，随着时间推移，这样的构件将变成实质上无错误的。因此，软件中使用的可重用构件越多，软件的可靠性越高，改正性维护需求就越少。
(2) 很容易修改可重用的软件构件使之再次应用在新环境中，因此，软件中使用的可重用构件越多，适应性和完善性维护也就越容易
文档
文档是影响软件可维护性的决定因素。由于长期使用的大型软件系统在使用过程中必然会经受多次修改，所以文档比程序代码更重要。
软件文档应该满足下述要求： (⑴)必须描述如何使用这个系统，没有这种描述时即使是最简单的系统也无法使用。 (2) 必须描述怎样安装和管理这个系统。 (3) 必须描述系统需求和设计。 (4) 必须描述系统的实现和测试，以便使系统成为可维护的。
文档可以分为用户文档和系统文档两类。
1.用户文档 用户文档是用户了解系统的第一步，它应该能使用户获得对系统的准确的初步印象。
(1) 功能描述 (2) 安装文档 (3) 使用手册 (4) 参考手册（要完整） (5) 操作员指南(如果需要有系统操作员的话)
2.系统文档 所谓系统文档指从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档。描述系统设计、实现和测试的文档对于理解程序和维护程序来说是极端重要的。
和用户文档类似，系统文档的结构也应该能把读者从对系统概貌的了解，引导到对系统每个方面每个特点的更形式化更具体的认识
可维护性复审
预防性维护
软件再工程过程
