由于系统维护所要解决的问题可能来自系统整个开发周期的各个阶段，因此承担维护工作的人员应对开发阶段的整个过程、每个层次的工作都有所了解，从需求、分析、设计一直到编码、测试等，并且应具有较强的程序调试和排错能力，这些对维护人员的知识结构、素质和专业水平有较高的要求。由于问题可能来源于系统的各个组成部分，产生于系统开发的各个阶段，因此系统维护工作并不仅仅是针对源程序代码，而且包括系统开发过程中的全部开发文档。系统维护中的编码本身造成的错误比例并不高，仅占4%左右，而绝大部分问题源于系统分析和设计阶段。通常，理解别人编写的程序很难，且难度随着软件配置文档的减少而增加；绝大多数系统在设计和开发时并没有很好地考虑将来可能的修改，如有些模块不够独立，牵一发而动全身；系统维护工作相对缺乏挑战性，使系统维护人员队伍不稳定。系统维护工作是技术性强的管理工作。系统投入运行后，应用部门必须建立相应的组织，确定进行维护工作所应遵循的原则和规范化的过程，并建立一套适用于具体系统维护过程的文档及管理措施，以及进行复审的标准。

　　信息系统投入运行后，应用部门应设系统维护管理员，专门负责整个系统维护的管理工作；针对每个子系统或功能模块，应配备系统管理人员，他们的任务是熟悉并仔细研究所负责部分系统的功能实现过程，甚至对程序细节都有清楚的了解，以便于完成具体维护工作。系统变更与维护的要求常常来自于系统的一个局部，而这种维护要求对整个系统来说是否合理，应该满足到何种程度，还应从全局的观点进行权衡。因此，为了从全局上协调和审定维护工作的内容，每个维护要求都必须通过一个维护控制部门的审查批准后，才能予以实施，这个维护控制部门，应该由业务管理部门和系统管理部门共同组成，以便于从业务功能和技术实现两个角度控制维护内容的合理性和可行性。

　　用户的维护申请都以书面形式的维护申请报告向维护管理员提出。对于纠错性维护，报告中必须完整描述出现错误的环境，包括输入/输出数据以及其他系统状态信息；对于适应性和完善性维护，应在报告中提出简要的需求规格说明书。维护管理员根据用户提交的申请，召集相关的系统管理员对维护申请报告的内容进行核评。情况属实，则依维护性质、内容、预计工作量、缓急程度或优先级以及修改所产生的变化结果等，编制维护报告，提交维护管理部门审批。

　　维护管理部门从整个系统出发，从合理性和技术可行性两个方面对维护要求进行分析和审查，并对修改所产生的影响做充分的估计。对于不妥的维护要求要在与用户协商的条件下予以修改或撤消。通过审批的维护报告，由维护管理员根据具体情况制定维护计划。对于纠错性维护，估计其缓急程度，如果维护要求十分紧急，严重影响系统的运行，则应安排立即开始修改工作；如果问题不是很严重，可与其他维护项目结合起来从维护开发资源上统筹安排；对于适应性或完善性维护要求，高优先级的安排在维护计划中，优先级不高的可视为一个新的开发项目组织开发。维护计划的内容应包括：工作的范围，所需资源，确认的需求，维护费用，维修进度安排以及验收标准等。维护管理员将维护计划下达给系统管理员，由系统管理员按计划进行具体的修改工作。修改后应经过严格的测试，以验证维护工作的质量。

　　测试通过后，再由用户和管理部门对其进行审核确认，不能完全满足要求的应返工修改。只有经确认的维护成果才能对系统的相应文档进行更新，最后交付用户使用。为了评价维护的有效性，确定系统的质量，记载系统所经历过的维护内容，应将维护工作的全部内容(如维护对象、规模、语言，运行和错误发生的情况，维护所进行的修改情况，以及维护所付出的代价等)，以规范化文档的形式记录下来，形成历史资料备查。

　　维护产生的修改对于系统也存在一些副作用：对源代码的修改可能会引入新的错误；对数据结构进行修改，可能会带来数据的不匹配等错误，在修改时必须参照系统文件中关于数据结构的详细描述和模块间的数据交叉引用表，以防局部的修改影响全局的整体作用；任何对源程序的修改，如不能对相应的文档进行更新，造成源程序与文档的不一致，必将给今后的应用和维护工作造成混乱。

　　系统维护人员应职责明确，保持人员的稳定性，对每个子系统或模块至少应安排两个人共同维护，避免对个人的过分依赖。在系统未暴露出问题时，就应着重于熟悉掌握系统的有关文档，了解功能的程序实现过程，一旦提出维护要求，立即高效优质地实施维护。最后，应注意系统维护的限度问题。即当系统生命周期结束的时，应及时采用新系统。