生产用软件维护管理制度【非常经典，打灯笼都找不到的好资料】.doc

生产用软件维护管理制度 总则 本制度适用于应用系统已开发或采购完毕并正式上线、且由软件开发组织移交给应用管理组织之后，所发生的生产应用系统（以下简称应用系统）运行支持及系统变更工作。 本制度所指的软件开发组织，在公司总部层面为信息技术部各软件开发处，在分公司层面为信息技术部相关的软件开发科室或岗位；本制度所指的应用管理组织，在总公司层面为信息技术部应用管理处，在分公司层面为信息技术部相应的应用维护科室或岗位。 生产用软件系统的运行支持 运行支持工作可分为下面两种类型：运行维护和技术支持。运行维护指后台程序（批作业）运行、数据库备份、数据清理等日常工作；技术支持指提供系统使用、技术知识上的帮助。 生产用软件系统的运行维护工作由各级公司信息部门应用维护组织完成。技术支持工作由各级公司信息部门应用维护组织向本公司用户部门和下级公司信息部门应用管理组织提供。 应用管理的主要职责是：处理总部各部门和分公司对目前已上线系统的应用问题的工作主要由应用管理处负责，主要工作包括提供相应的技术咨询及技术支持，以及接收问题报告，并对问题加以解决。 技术咨询指为通过电话、电子邮件、技术论坛等形式为分公司及总公司相关部门提供关于应用系统的使用及维护等方面的技术支持；接收问题报告指接收由下级分公司上报的，以“问题报告单”形式反映的应用系统问题，并加以处理、反馈和汇总整理。 为方便管理，提高服务效率，应制定默认处理制度。即要求回复的工作或问题，在默认的时间内未接到回复的按默认办法处理。 负责处理具体应用管理的人员应每月出具问题报告，统计汇总、分析经办的问题，提出相关意见和建议，并请直管领导签字审阅。 接收问题，提供咨询等工作中发生的文档应妥善保存，纸质文档保存时间为2年，电子文档每年以CDR进行统一刻录，保存时间为5年。 要求各级单位以问题报告单的形式报告应用系统出现的问题。上级单位接收问题上报的时间以收到问题报告单位问题报告单的时间为准。问题报告单位应对其反映的问题做出初步定位。 问题报告单位填写问题报告单应规范，并详细描述问题出现时的状况、当时的环境以及错误提示信息等一切有助于准确定位问题的信息。同时，应完整填写上报人信息及联系方式（电话、OA），以方便联络。对于不符合要求的问题报告单应返回问题报告单位重新填写。 接到用户通过电话、OA提出的咨询应尽量给予对方满意的解答。电话、OA提出的咨询不视为正式的问题上报。 论坛主要作为供各层信息技术人员交流经验的平台。对于正式问题上报还是应采取提交“问题报告单”形式上报；问题咨询应通过OA或电话形式。应用管理处应用系统维护岗的负责同志应有取舍的对论坛中有共性的问题进行答复。 对属于操作类的问题，须判断属于误操作，还是存在脏数据，应按问题的性质分别给出处理办法。如果发现问题属于系统中存在脏数据，应请当地问题单位及时清理。如其中数据涉及数据拥有部门（如：财务部、业管部等），应向相关部门申请，在获得书面同意后方可进行修改。同时，如果需要直接修改后台数据库中的数据，具体流程应参考运行管理流程中关于修改后台数据库中的相关规定。 生产用软件系统的系统变更 系统变更工作可分为下面三类类型：功能完善维护、系统缺陷修改、统计报表生成。功能完善维护指根据业务部门的需求，对系统进行的功能完善性或适应性维护；系统缺陷修改指对一些系统功能或使用上的问题所进行的修复，这些问题是由于系统设计和实现上的缺陷而引发的；统计报表生成指为了满足业务部门统计报表数据生成的需要，而进行的不包含在应用系统功能之内的数据处理工作。 系统变更工作以任务形式由需求方（一般为业务部门）和维护方（一般为信息部门的应用维护组织和软件开发组织，还包括合作厂商）协作完成。系统变更过程类似软件开发，大致可分为四个阶段：任务提交和接受、任务实现、任务验收和程序下发上线。具体流程，前三个阶段参见《系统变更流程》，第四个阶段参见《程序下发流程》。 因问题和紧急事件处理引发的系统变更处理，具体流程参见《问题变更流程》和《紧急变更流程》。 系统变更需求只能由应用系统具体拥有部门作为需求部门提出，由具体开发应用系统的信息技术部作为维护部门接受。需求部门变更需求提出人应将变更需求整理成《内部任务书》，以部门名义提交给信息技术部，《内部任务书》在提交前应由需求部门负责人审批。维护部门由应用管理组织负责接受需求、分析需求，并提出系统变更建议，对《内部任务书》的处理意见应经过信息技术部负责人审批。 应用管理组织在变更需求的分析过程中应评估并核实变更对现有运行带来的影响，并给出优先级分配的建议。上述评估结果和处理意见应做为处理意见的一部分包含于《内部任务书》中。 需求部门对变更需求本身的变更，应以《需求变更书》的形式向维护部门正式提出。 应用管理组织负责系统变更需求的实现，按照分配的优先级安排