软件系统运行维护分为：改正性维护、适应性维护、完善性维护、预防性维护。为您讲解软件系统运行维护的相关知识。
软件系统运行维护
改正性维护。软件交付使用后，必然会有一部分隐藏的错误被带到运行阶段来，在某些特定的使用环境下就会暴露出来。为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应进行的诊断和改正错误的过程，就叫做改正性维护。
适应性维护。随着计算机的飞速发展，外部环境（新的硬、软件配置）或数据环境（数据库、数据格式、数据输入∕输出方式、数据存储介质）可能发生变化，为了使软件适应这种变化，而去修改软件的过程就叫做适应性维护。
完善性维护。在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。这种情况下进行的维护活动叫做完善性维护。
在维护阶段的最初一、二年，改正性维护的工作量较大。随着错误发现率急剧降低，并趋于稳定，就进入了正常使用期。然而，由于改造的要求，适应性维护和完善性维护的工作量逐步增加。实践表明，在几种维护活动中，完善性维护所占的比重最大，来自用户要求扩充、加强软件功能、性能的维护活动约占整个维护工作的50%。
预防性维护，除了以上三类维护之外，还有一类维护活动，叫做预防性维护。这是为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。通常，预防性维护定义为：“把今天的方法学用于昨天的系统以满足明天的需要”。也就是说，采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试。
软件维护中的程序修改
全面、准确、迅速地理解程序是决定维护成败和质量好坏的关键，因此，软件的可理解性和文档的质量非常重要。包括：理解程序的功能和目标；掌握程序的结构信息，即从程序中细分出若干结构成分。如程序系统结构、控制结构、数据结构和输入/输出结构等；了解数据流信息，即所涉及到的数据来源何处，在哪里被使用；了解控制流信息，即执行每条路径的结果；理解程序的操作（使用）要求。
为了容易地理解程序，要求自顶向下地理解源程序的程序结构和数据结构，可采用如下方法。
分析程序结构图：分析各个过程的源代码，建立一个直接调用矩阵或调用树；建立过程的间接调用矩阵；分析各个过程的接口，估计更改的复杂性。
数据跟踪：建立各层次的程序级上的接口图，展示各模块或过程的调用方式和接口参数；利用数据流分析方法，对过程内部的一些变量进行跟踪；维护人员通过这种数据流跟踪，可获得有关数据在过程间如何传递，在过程内如何处理等信息。
控制跟踪：控制流跟踪同样可在结构图基础上或源程序基础上进行。可采用符号执行或实际动态跟踪的方法，了解数据如何从一个输入源到达输出点的。
对程序的修改，必须事先做出计划，有步骤地、周密有效地实施。程序的修改计划要考虑人员和资源的安排，内容主要包括：规格说明信息，如数据修改、处理修改、作业控制语言修改、系统之间接口的修改等；维护资源，如新程序版本、测试数据、所需的软件系统、计算机时间等；人员，如程序员、用户相关人员、技术支持人员、厂家联系人、数据录入员等。
针对以上每一项，要说明必要性、从何处着手、是否接受、日期等。通常可采用自顶向下的方法，在理解程序的基础上，研究程序的各个模块、模块的接口及数据库，从全局的观点提出修改计划。依次把要修改的及那些受修改影响的模块和数据结构分离出来。通常要做如下工作。
识别受修改影响的数据；
识别使用这些数据的程序模块；
对于程序模块，按是产生数据、修改数据还是删除数据进行分类；
识别对这些数据元素的外部控制信息；
识别编辑和检查这些数据元素的地方；
隔离要修改的部分。
要谨慎地修改程序，尽量保持程序的风格及格式，要在程序清单上注明改动的指令；不要删除程序语句，除非完全肯定它是无用的；不要试图共用程序中已有的临时变量或工作区，为了避免冲突或混淆用途，应自行设置自己的变量；插入错误检测语句；在修改过程中做好修改的详细记录，消除变更中任何有害的副作用（波动效应）。
在修改程序中，要注意副作用的影响，所谓副作用是指因修改软件而造成的错误或其他不希望发生的情况，有如下三种。
修改代码的副作用。在使用程序设计语言修改源代码时，可能引入错误。如删除或修改一个子程序、删除或修改一个标号、删除或修改一个标识符、改变程序代码的时序关系、改变占用存储的大小、改变逻辑运算符、修改文件的打开或关闭、改进程序的执行效率以及把设计上的改变翻译成代码的改变、为边界条件的逻辑测试做出改变时等。
修改数据的副作用。在修改数据结构时，有可能造成软件设计与数据结构不匹配，因而导致软件出错。数据副作用就是修改软件信息结构导致的结果。例如，在重新定义局部的或全局的常量、 重新定义记录或文件的格式、增大或减小一个数组或高层数据结构的大小、修改全局或公共数据、重新初始化控制标志或指针、重新排列输入／输出或子程序的参数，容易导致设计与数据不相容的错误。
文档的副作用。对数据流、软件结构、模块逻辑或任何其他有关特性进行修改时，必须对相关技术文档进行相应修改，否则会导致文档与程序功能不匹配，缺省条件改变，新错误信息不正确等错误。使得软件文档不能反映软件的当前状态。对于用户来说，软件事实上就是文档。如果对可执行软件的修改不反映在文档里，就会产生文档的副作用。例如，对交互输入的顺序或格式进行修改，如果没有正确地记入文档中，就可能引起重大的问题。过时的文档内容、索引和文本可能造成冲突，引起用户的失败和不满。因此，必须在软件交付之前对整个软件配置进行评审，以减少文档的副作用。
在将修改后的程序提交用户之前，需要用以下的方法进行充分的确认和测试，以保证整个修改后的程序的正确性。
1．静态确认
修改软件，伴随着引起新的错误的危险。为了能够做出正确的判断，验证修改后的程序至少需要两个人参加。要检查修改是否涉及到规格说明？修改结果是否符合规格说明？有没有歪曲规格说明？程序的修改是否足以修正软件中的问题？源程序代码有无逻辑错误？修改时有无修补失误？修改部分对其他部分有无不良影响（副作用）？
2．计算机确认
在充分进行了以上确认的基础上，要用计算机对修改程序进行确认测试。确认测试顺序：先对修改部分进行测试，然后隔离修改部分，测试程序的未修改部分，最后再把它们集成起来进行测试，这种测试称为回归测试。准备标准的测试用例；充分利用软件工具帮助重新验证过程；在重新确认过程中，需邀请用户参加。
3．维护后的验收
交付新软件之前，维护主管部门要检验：全部文档是否完备并已更新；所有测试用例和测试结果已经正确记载；记录软件配置所有副本的工作已经完成；维护工序和责任已确定。