软件变更与维护管理制度.doc

软件变更与维护管理制度 总则 为规范软件变更与维护管理，提高软件管理水平，优化软件变更与维护管理流程，特制定本制度。 软件变更与维护管理主要包括一般性变更、紧急变更、用户测试、版本控制、系统更新和权限管理等内容。 本制度适用于DXC总部和各分子公司。 一般性变更流程 需求部门提出系统变更需求，并将变更需求整理成《变更申请书》（附件三），由部门负责人审批后提交给信息部。 信息部负责接受需求、分析需求，并提出系统变更建议。信息部负责人审批《变更申请书》。 信息部根据自行开发、合作开发和外包开发的不同要求组织实现系统变更需求，产生供发布的程序。 信息部将所有的变更请求记录在《任务管理表》（附件四）中，并按照优先级安排实施的先后次序进行跟踪处理。 信息部负责对系统变更过程的文档进行归档管理，所有文档至少保存三年。详细流程参见《系统变更流程》（附件一）。 紧急变更流程 对于紧急变更，需求部门可以通过电子邮件或传真等书面形式提出申请。 信息部按照事先明确的紧急变更定义做出判断，确定其优先级和影响程度，并进行相应的处理。 紧急变更过程中应使用专设系统用户帐号，由专责部门或人员启动紧急修改变更程序。信息部应对紧急变更的处理进行规范的文档记录。 在紧急事件处理完成后，必须补办正式、完整的文档。详细流程参见《紧急变更流程》（附件二）。 系统的版本控制 软件变更时，加强版本控制，确保每次在必威体育精装版的代码基础上进行更改。 应对下发的软件进行版本控制，由专责人员负责发布软件的版本管理。 系统变更的责权分离 应加强对运行环境的访问控制，只允许授权的用户访问运行环境中的应用系统。通过物理和逻辑隔离的手段，控制对运行环境的访问。 限制开发人员对运行环境中应用程序文件夹的访问权限，只有经过授权的人员才拥有相应的权限。 对授权访问运行环境的人员进行详细记录，并定期进行检查。 普通用户只能通过前台登录系统，不能通过后台进行操作。 系统维护人员不应该拥有前台应用程序的访问权限，更不应该在前台应用程序中担任实际的操作任务。 禁止系统维护人员共享操作系统级别的账号。 附则 本制度由公司总部信息部负责解释和修订。 本制度自发布之日起开始执系统变更流程步骤： 一、任务提交和接受： 本流程中需求部门为应用系统构建时提出需求的业务部门，维护部门为负责按照需求实际构建应用系统的信息部。流程如下： 需求形成： 需求方根据业务的需要，结合收到的其他用户部门要求，填写《变更申请书》。 需求方负责人审批 需求方将《变更申请书》报请部门负责人签字批准后，经指定途径提交给信息部相关系统维护人员。 需求评估 系统维护人员审查需求，会同相关开发负责人进行需求评估，产生评估结果。 信息部负责人审批 系统维护人员将评估结果附在《变更申请书》后，报请部门负责人签字批准后，正式向开发负责人下达任务。 如果任务实现由合作厂商完成，则由开发负责人按照与合作厂商签订的技术服务合同，填写《厂商维护申请单》（附件五），报请部门负责人签字批准后，正式向合作厂商下达任务。 任务登记 为了便于追踪各个系统变更需求的状态，维护人员需要对需求进行登记。 信息部每周对《任务管理表》中的需求完成状态进行更新，以便信息部负责人监控系统变更任务进度。 二、任务实现 信息部开发负责人（或由开发负责人会同合作厂商）根据《变更申请书》的需求描述，按照与软件开发流程同样的步骤，进行分析、设计、编码、测试，最终完成系统变更需求。 三、任务验收及用户测试 任务验收以需求部门为主，信息部配合完成。 任务开发测试完成后，由开发负责人通知维护人员，并提供可用于验收测试的文档和程序升级包。系统维护人员检查开发负责人提交的资料是否完整、有效，版本是否必威体育精装版，并对移交程序的内容进行验收并形成记录。 维护人员制定用户测试计划，由需求部门按照测试计划构建验收测试环境，进行验收测试并对测试内容进行记录。验收测试通过后，由需求部门在《验收报告书》（附件六）上出具验收结论并会同信息部门签署下发意见。 如果任务实现由合作厂商完成，则由开发负责人员在内部任务验收完成后，根据需求部门的验收意见，在《厂商维护申请单》上出具验收结论并会同需求部门签署下发意见。 四、程序下发及系统上线 下发程序经需求部门正式验收后由系统维护人员将要发布的程序进行打包下发。程序下发前，系统维护人员需填写《程序下发申请表》（附件七）并经过维护部门负责人审批。 如果通过网络发布程序，则需通过指定路径或程序服务器发布，并且对相关访问人员的权限进行控制。 下发程序接收公司的系统维护人员在收到下发的程序包后，联系需求部门进行安装测试，测试结束后在《系统上线申请表》（附件八）的“需求部门意见”中填写验收意见，并签字确认。 程序上线实施完毕以后，系统维护人员需填写《升级情况反馈表》（附件九），填写完毕后