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