系统维护
为了清除系统运行中发生的故障和错误，软、硬件维护人员要对系统进行必要的修改与完善；为了使系统适应用户环境的变化，满足新提出的需要，也要对原系统做些局部的更行，这些工作称为系统维护。
系统维护是面向系统中各种构成要素的，根据维护对象的不同，系统维护的内容可以分为以下几类：
系统维护的重点是系统应用软件的维护工作，按照软件维护的不同性质，可以划分为下面四种类型：
系统的维护不仅范围广，而且影响因素很多。通常，在进行某项维护修改工作之前，需要考虑下列3方面的因素：
系统维护工作是直接受到系统可维护性影响的。可维护性是指对系统进行维护的难易程度的度量，影响系统可维护性主要有以下三个因素：
维护就意味着对系统进行修改，修改对于系统来讲有一些副作用，即由于修改而出现错误或其他不合要求的行为，这种副作用主要来自3个方面：第一，对源代码的修改可能会引入新的错误，一般可以通过回归测试发现这类副作用；第二，对数据结构进行修改，如局部或全局变量的重新定义，文件格式的修改等，可能会带来数据的不匹配等错误，在修改时必须参照系统文件中关于数据结构的详细描述和模块间的数据交叉引用表，以防局部的修改影响全局的整体作用；第三，任何对源程序的修改，如不能对相应的文档进行更新，造成源程序与文档的不一致，必将给今后的应用和维护工作造成混乱。在系统维护中，应该注意以上3个问题，以避免修改带来的副作用。
1、任务
系统维护的任务是改正软件系统在使用过程中发现的隐含错误，扩充在使用过程中用户提出的新的功能及性能要求，其目的是维护软件系统的“正常运作”。这阶段的文档是软件问题报告和软件修改报告，它记录发现软件错误的情况以及修改软件的过程。
2、内容和类型
系统维护内容
系统维护是面向系统中各种构成要素的，根据维护对象的不同，系统维护的内容可以分为以下几类：
1.系统应用程序维护。系统的业务处理过程是通过应用材料库的运行而实现的，一旦程序发生问题或业务发生变化，就必然地引起程序的修改和调整，因此系统维护的主要活动就是对程序进行维护。
2.数据维护。业务处理对数据的需求是不断发生变化的，除了系统中主体业务数据的定期正常更新外，还有许多数据需要进行不定期的更新，或者随环境及业务的变化而进行调整，以及数据内容的增加，数据结构的调整。此外，数据的备份与恢复等都是数据维护的工作内容。
3.代码维护。随着系统应用范围的扩大，应用环境的变化，系统中的各种代码都需要进行一定程度的增加、修改、删除，以及设置新的代码。
4.硬件设备维护。主要是指对主机及外设的日常维护和管理，如机器部件的清洗、润滑，设备故障的检修，易损部件的更换等，都应由专人负责，定期进行，以保证系统正常有效地运行。
5.机构和人员的变动。信息系统是人机系统，人工处理也占有重要地位，人的作用占主导地位。为了使信息系统的流程更加合理，有时涉及到机构和人员的变动。这种变化往往也会影响对设备和程序的维护工作。
系统维护的类型
系统维护的重点是系统应用软件的维护工作，按照软件维护的不同性质，可以划分为下面四种类型：
1.纠错性维护，就是诊断和修正系统中遗留的错误。因此在系统投入运行后频繁的实际应用过程中，就有可能暴露出系统内隐藏的错误。诊断和修正系统中遗留的错误，就是纠错性维护。纠错性维护时在系统运行中发生异常或故障时进行的，这种错误往往是遇到了从未用过的输入数据组合或是在与其他部分接口处产生的，因此只是在某些特定的情况下发生。有些系统运行多年以后才暴露出在系统开发中遗留的问题，这是不足为奇的。
2.适应性维护，是为了使系统适应环境的变化而进行的维护工作。一方面计算机科学技术迅速发展，硬件的更新周期越来越短，操作系统不断推出新的版本，外部设备也经常有所增加和修改，这是必然要求信息系统能够适应新的软硬件环境，以提高系统的性能和运行效率；另一方面，信息系统的使用寿命在延长，即应用对象也在不断发生变化，机构的调整，管理*的改变、数据与信息需求的变更等都将导致系统不能适应新的应用环境。如代码改变、数据结构变化、数据格式以及输入/输出方式的变化、数据存储介质的变化等，都将直接影响系统的正常工作。因此有必要对系统进行调整，使之适应应用对象的变化，满足用户的需求。
3.完善性维护，为了扩充原有系统的功能，增加一些在软件需求规范书中没有规定的功能与性能特征，以及对处理效率和编写程序的改进，提供其性能而进行的系统维护工作。例如，有时可将几个小程序合并成一个单一的运行良好的程序，从而提高处理效率；增加数据输出的图形方式；增加联机在线帮助功能；调整用户界面等。尽管这些要求在原来系统开发的需求规格说明书中并没有，但用户要求在原有系统基础上进一步改善和提高；并且随着用户对系统的使用和熟悉，这种要求可能不断提出。为了满足这些要求而进行的系统维护工作就是完善性维护。
4.预防性维护，系统维护工作应进行主动的预防性维护，即选择那些还有较长使用寿命，目前尚能正常运行，但可能将要发生变化或调整的系统进行维护。例如，将目前能应用的报表功能改成通用报表生成功能，以应付今后报表内容和格式可能的变化，根据对各种维护工作分布情况的统计结果，一般纠错性维护占21%，适应性维护工作占25%，完善性维护达到50%，而预防性维护以及其他类型的维护仅占4%，可见系统维护工作中，一半以上的工作室完善性维护。
3、工作特点
采用结构化开发方法与否对系统维护工作有极大影响
如果系统开发没有采用结构化分析与设计方法，则相应的维护也只能是非结构化维护。因为这时系统软件配置的惟一成分是程序源代码，一旦有系统维护的需求时，维护工作只能从艰苦的评价程序代码开始。由于没有完整规范的设计开发文档，无程序内部文档，对于软件结构、数据结构、系统接口以及设计中的各种技巧很难弄清，如果编码风格再差一些，则系统维护工作十分艰难，因此，有许多软件人员宁可重新编码，也不愿意维护这种系统。另一方面，由于无测试文档，不能进行回归测试，对于维护后的结果难以评价。
相反，如果系统开发采用了结构化方法，则系统交付时完整的软件配置文档，维护系统接口等特点，在考虑到修改可能带来影响下，设计修正错误的途径。然后修改设计，在与设计相应的源程序上进行修改，使用测试说明书中包含的测试方案进行回归测试。可见经过结构化开发的系统，将大大减少维护的工作量，提高软件质量。
系统维护具有很高的代价
首先，有形的代价直接来自维护工作本身，维护工作可分为两部分，一部分为非生产性活动，主要是理解源程序代码的功能，解释数据结构、接口特定和性直线度等。这部分工作量和费用与系统的复杂程度、维护人员的经验水平以及对系统的熟悉程度密切相关；另一部分生产性活动，主要是分析评价、修改设计和编写程序代码等。
另外，许多无形的代价来自维护所产生的效果和影响上。由于开发人员和其他开发资源越来越多地被束缚在系统维护工作中，开发的系统越多，维护的负担越重，这将导致开发人员完全没有时间和潜力还有精力从事新系统的开发，从而耽误甚至丧失了开发良机。此外，合理的维护要求不能及时满足，将引起用户的不满；维护过程中引入新的错误，使系统3可靠性下降等问题将带来很高的维护代价。
系统维护工作的对象是整个系统的配置
由于问题可能来源于系统的各个组成部分，产生于系统开发的各个阶段，因此系统维护工作并不仅仅是针对源程序代码，而且包括系统开发过程中的全部开发文档。
系统维护工作对维护人员要求较高
系统维护所要解决的问题可能来自系统整个开发周期的各个阶段，因此承担维护工作的人员应对开发阶段的整个过程、每个层次的工作都有所了解，从需求、分析、设计一直到编码、测试等，并且应具有较强的程序调试和排错能力，这些对维护人员的知识结构、素质和专业水平有较高的要求。
系统维护中经常遇到的问题
系统维护中的绝大部分问题源于系统分析和设计阶段，而编码本身造成的错误比例并不高，仅占4%左右。理解别人编写的程序很难，而且这种难度随着软件配置文档的减少而增加。从实际情况来看，绝大多数系统在设计和开发时并没有很好地考虑将来可能的修改，如有些模块不够独立，牵一发而动全身。同时，系统维护工作相对开发工作者来讲，不惧挑战性、不够吸引人，使系统维护人员队伍不稳定。
4、考虑因素
系统的维护不仅范围广，而且影响因素很多。通常，在进行某项维护修改工作之前，需要考虑下列3方面的因素：
维护背景1.系统的当前情况
2.维护对象
3.维护工作的复杂性与规模
维护工作的影响
1.对新系统目标的影响
2.对当前工作进度的影响
3.对本系统其他部分的影响
4.对其他系统的影响
资源要求
1.对维护提出的时间要求
2.维护所需要费用
3.维护所需的工作人员
5、系统的可维护性
系统维护工作是直接受到系统可维护性影响的。可维护性是指对系统进行维护的难易程度的度量，影响系统可维护性主要有以下三个因素：
1.可理解性，表现为外来读者理解系统的结构、接口、功能和内部过程的难易程度。
2.可预测性，表现为对系统进行诊断和测试的难易程度。
3.可修改性，表现为对系统各部分进行修改的难易程度。
提高系统可维护性应当从系统分析与设计开始，直至系统实施的系统开发全过程。
6、系统的组织与管理
系统维护工作，首先必须建立一个维护组织，确定进行维护工作所应遵循的原则和规范化的过程，此外还应建立一套适用于具体系统过程的文档及管理措施，以及进行复审的标准。
信息系统投入运行后，应设系统维护管理员，专门负责整个系统维护的管理工作；针对每个子系统或功能模块，应配备系统管理人员。每个维护要求都必须通过一个维护控制部门的审查批准后，才能予以实施，这个维护控制部门，应该由业务管理部门和系统管理部门共同组成，以便于从业务功能和技术实现两个角度控制维护内容的合理性和可行性。
系统维护的组织管理如图。
系统维护组织管理
系统维护工作的程序图，如图。
系统维护工作程序
系统维护之所有要按照严格的步骤进行，是为了防止未经允许的擅自修改系统，因为无论是用户直接找程序人员还是程序人员自行修改程序，都将引起系统混乱，如出现不及时更新文档造成程序与文档不一致，多个人修改的结果不一致，以及缺乏全局考虑的局部修改等。当然维护审批过程的环节多也可能带来反应速度慢，因此当系统发生恶性或紧急故障时，也即出现所谓“救火”的维护要求是，需立即动用资源解决问题，以保证业务工作的连续进行。
为了评价维护的有效性，确定系统的质量，记载系统所经历过的维护内容，应将维护工作的全部内容以文档的规范化形式记录下来，主要包括维护对象、规模、语言、运行和错误发生的情况，维护所进行的修改情况，以及维护所付出得代价等，作为系统开发文档的一部分，形成历史资料，以便于日后备查。
维护就意味着对系统进行修改，修改对于系统来讲有一些副作用，即由于修改而出现错误或其他不合要求的行为，这种副作用主要来自3个方面：第一，对源代码的修改可能会引入新的错误，一般可以通过回归测试发现这类副作用；第二，对数据结构进行修改，如局部或全局变量的重新定义，文件格式的修改等，可能会带来数据的不匹配等错误，在修改时必须参照系统文件中关于数据结构的详细描述和模块间的数据交叉引用表，以防局部的修改影响全局的整体作用；第三，任何对源程序的修改，如不能对相应的文档进行更新，造成源程序与文档的不一致，必将给今后的应用和维护工作造成混乱。在系统维护中，应该注意以上3个问题，以避免修改带来的副作用。
另外，在安排系统维护人员工作时应注意，不仅要使每个人员的维护职责明确，而且对每一个子系统或模块至少应安排两个人可以进行维护工作，这样可以避免系统维护工作对某个人的过分依赖，防止由于工作调动等原因，使维护工作受到影响，应尽量保持维护人员队伍的稳定性，在系统运行尚未暴露出问题时，维护人员应着重于熟悉掌握系统的有关文档，了解功能的程序实现过程，一旦维护要求提出后，他们就应快速高质量地完成维护工作。
最后，应注意系统维护的限度问题。系统维护是在原有系统的基础上进行修改，调整和完善。使系统能够不断适应新环境、新需要。但一个系统终会有生命周期结束的时候，当对系统的修改不再奏效，或修改的困难很多且工作量很大、花费过大，以及改进、完善的内容远远超出原系统的设计要求时，就应提出研制新系统的要求，从而开始一个新的系统生命周期。