管理信息系统在完成系统实施、投入正常运行之后，就进入了系统运行与维护阶段。一般信息系统的使用寿命短则4-5年，长则可达10年以上，在信息系统的整个使用寿命中，都将伴随着系统维护工作的进行。系统维护的目的是要保证管理信息系统正常而可靠地运行，并能使系统不断得到改善和提高，以充分发挥作用。因此，系统维护的任务就是要有计划、有组织地对系统进行必要的改动，以保证系统中的各个要素随着环境的变化始终处于最新的、正确的工作状态。

系统维护工作在整个系统生命周期中常常被忽视。人们往往热衷于系统开发，当开发工作完成以后，多数情况下开发队伍被解散或撤走，而在系统开始运行后并没有配置适当的系统维护人员。这样，一旦系统发生问题或环境发生变化，最终用户将无从下手，这就是为什么有些信息系统在运行环境中长期与旧系统并行运行不能转换，甚至最后被废弃的原因。随着信息系统应用的深入，以及使用寿命的延长，系统维护的工作量将越来越大。系统维护的费用往往占整个系统生命周期总费用的60%以上，因此有人曾以浮在海面的冰山来比喻系统开发与维护的关系，系统开发工作如同冰山露出水面的部分，容易被人看到而得到重视，而系统维护工作如同冰山浸在水下部分，体积远比露出水面的部分大得多，但由于不易被人看到而常被忽视：从另一方面来看，相对具有“开创性”的系统开发来讲，系统维护工作属于“继承性”工作，挑战性不强，成绩不显著，使很多技术人员不安心于系统维护工作，这也是造成人们重视开发而轻视维护的原因。但系统维护是信息系统可靠运行的重要技术保障，必须给予足够的重视。

为保证计算机系统能够正常运行而进行的定期检测、修理和优化。主要从硬件和软件方面入手。硬件包括计算机主要部件的保养和升级；软件包括计算机操作系统的更新和杀毒。

如果系统开发没有采用结构化分析与设计方法，则相应的维护也只能是非结构化维护。因为这时系统软件配置的惟一成分是程序源代码，一旦有系统维护的需求时，维护工作只能从艰苦的评价程序代码开始。由于没有完整规范的设计开发文档，无程序内部文档，对于软件结构、数据结构、系统接口以及设计中的各种技巧很难弄清，如果编码风格再差一些，则系统维护工作十分艰难，因此，有许多软件人员宁可重新编码，也不愿维护这种系统。另一方面，由于无测试文档，不能进行回归测试，对于维护后的结果难以评价。

相反，如果系统开发采用了结构化方法，则系统交付时有完整的软件配置文档，维护系统接口等特点，在考虑到修改可能带来影响的情况下，设计修正错误的途径。然后修改设计，在与设计相对应的源程序上进行的修改，使用测试说明书中包含的测试方案进行回归测试。可见经过结构化开发的系统，将大大减少维护的工作量，提高软件质量。

首先，有形的代价直接来自维护工作本身，维护工作可分为两部分，一部分为非生产性活动，主要是理解源程序代码的功能，解释数据结构、接口特点和性质限度等。这部分工作量和费用与系统的复杂程度（非结构化设计和缺少文档都会增加系统的复杂程度）、维护人员的经验水平以及对系统的熟悉程度密切相关；另一部分为生产性活动，主要是分析评价、修改设计和编写程序代码等。其工作量与系统开发的方式、方法、采用的开发环境有直接的关系。因此，如果系统开发途径不好，且原来的开发人员不能参加维护工作，则维护工作量和费用呈指数上升。例如，据1976年的报道，美国空军的飞行控制软件每条指令的开发成本是75美元，而维护成本大约是每条指令4000美元。统计表明，60%-70%的软件费用花在维护方面。

另外，许多无形的代价来自维护所产生的效果和影响上。由于开发人员和其他开发资源越来越多地被束缚在系统维护工作中，开发的系统越多，维护的负担越重，这将导致开发人员完全没有时间和潜力和精力从事新系统的开发，从而耽误甚至丧失了开发良机。此外，合理的维护要求不能及时满足，将引起用户的不满；维护过程中引入新的错误，使系统可靠性下降等问题将带来很高的维护代价。

因为系统维护所要解决的问题可能来自系统整个开发周期的各个阶段，因此承担维护工作的人员应对开发阶段的整个过程、每个层次的工作都有所了解，从需求、分析、设计一直到编码、测试等，并且应具有较强的程序调试和排错能力，这些对维护人员的知识结构、素质和专业水平有较高的要求。

由于问题可能来源于系统的各个组成部分，产生于系统开发的各个阶段，因此系统维护工作并不仅仅是针对源程序代码，而且包括系统开发过程中的全部开发文档。

系统维护中的绝大部分问题源于系统分析和设计阶段，而编码本身造成的错误比例并不高，仅占4%左右。理解别人编写的程序很难，而且这种难度随着软件配置文档的减少而增加。从实际情况来看，绝大多数系统在设计和开发时并没有很好地考虑将来可能的修改，如有些模块不够独立，牵一发而动全身。同时，系统维护工作相对开发工作者来讲，不具挑战性、不吸引人，使系统维护人员队伍不稳定。