系统维护之所有要按照严格的步骤进行，是为了防止未经允许的擅自修改系统，因为无论是用户直接找程序人还是程序人员自行修改程序，都将引起系统混乱，如出现不及时更新文档造成程序与文档不一致，多个人修改的结果不一致，以及缺乏全局考虑的局部修改等。当然维护审批过程的环节多也可能带来反应速度慢，因此当系统发生恶性或紧急故障时，也即出现所谓“救火”的维护要求是，需立即动用资源解决问题，以保证业务工作的连续进行。

为了评价维护的有效性，确定系统的质量，记载系统所经历过的维护内容，应将维护工作的全部内容以文档的规范化形式记录下来，主要包括维护对象、规模、语言、运行和错误发生的情况，维护所进行的修改情况，以及维护所付出得代价等，作为系统开发文档的一部分，形成历史资料，以便于日后备查。

维护旧意味着对系统进行修改，修改对于系统来讲有一些副作用，即由于修改而出现错误或其他不合要求的行为，这种副作用主要来自3个方面：第一，对源代码的修改可能会引入新的错误，一般可以通过回归测试发现这类副作用；第二，对数据结构进行修改，如局部或全局变量的重新定义，文件格式的修改等，可能会带来数据的不匹配等错误，在修改时必须参照系统文件中关于数据结构的详细描述和模块间的数据交叉引用表，以防局部的修改影响全局的整体作用；第三，任何对源程序的修改，如不能对相应的文档进行更新，造成源程序与文档的不一致，必将给今后的应用和维护工作造成混乱。在系统维护中，应该注意以上3个问题，以避免修改带来的副作用。

另外，在安排系统维护人员工作时应注意，不仅要使每个人员的维护职责明确，而且对每一个子系统或模块至少应安排两个人可以进行维护工作，这样可以避免系统维护工作对某个人的过分依赖，防止由于工作调动等原因，使维护工作受到影响，应尽量保持维护人员队伍的稳定性，在系统运行尚未暴露出问题时，维护人员应着重于熟悉掌握系统的有关文档，了解功能的程序实现过程，一旦维护要求提出后，他们就应快速高质量地完成维护工作。

最后，应注意系统维护的限度问题。系统维护是在原有系统的基础上进行修改，调整和完善。使系统能够不断适应新环境、新需要。但一个系统终会有生命周期结束的时候，当对系统的修改不再奏效，或修改的困难很多且工作量很大、花费过大，以及改进、完善的内容远远超出原系统的设计要求时，就应提出研制新系统的要求，从而开始一个新的系统生命周期。