生产用软件维护管理制度

生产用软件维护管理制度总则本制度适用于应用系统已开发或采购完毕并正式上线、且由软件开发组织移交给应用管理组织之后，所发生的生产应用系统（以下简称应用系统）运行支持及系统变更工作。本制度所指的软件开发组织，在公司总部层面为信息技术部各软件开发处，在分公司层面为信息技术部相关的软件开发科室或岗位；本制度所指的应用管理组织，在总公司层面为信息技术部应用管理处，在分公司层面为信息技术部相应的应用维护科室或岗位。生产用软件系统的运行支持运行支持工作可分为下面两种类型：运行维护和技术支持。运行维护指后台程序（批作业）运行、数据库备份、数据清理等日常工作；技术支持指提供系统使用、技术知识上的帮助。生产用软件系统的运行维护工作由各级公司信息部门应用维护组织完成。技术支持工作由各级公司信息部门应用维护组织向本公司用户部门和下级公司信息部门应用管理组织提供。应用管理的主要职责是：处理总部各部门和分公司对目前已上线系统的应用问题的工作主要由应用管理处负责，主要工作包括提供相应的技术咨询及技术支持，以及接收问题报告，并对问题加以解决。技术咨询指为通过电话、电子邮件、技术论坛等形式为分公司及总公司相关部门提供关于应用系统的使用及维护等方面的技术支持；接收问题报告指接收由下级分公司上报的，以“问题报告单”形式反映的应用系统问题，并加以处理、反馈和汇总整理。为方便管理，提高服务效率，应制定默认处理制度。即要求回复的工作或问题，在默认的时间内未接到回复的按默认办法处理。负责处理具体应用管理的人员应每月出具问题报告，统计汇总、分析经办的问题，提出相关意见和建议，并请直管领导签字审阅。接收问题，提供咨询等工作中发生的文档应妥善保存，纸质文档保存时间为2年，电子文档每年以CDR进行统一刻录，保存时间为5年。要求各级单位以问题报告单的形式报告应用系统出现的问题。上级单位接收问题上报的时间以收到问题报告单位问题报告单的时间为准。问题报告单位应对其反映的问题做出初步定位。问题报告单位填写问题报告单应规范，并详细描述问题出现时的状况、当时的环境以及错误提示信息等一切有助于准确定位问题的信息。同时，应完整填写上报人信息及联系方式（电话、OA），以方便联络。对于不符合要求的问题报告单应返回问题报告单位重新填写。接到用户通过电话、OA提出的咨询应尽量给予对方满意的解答。电话、OA提出的咨询不视为正式的问题上报。论坛主要作为供各层信息技术人员交流经验的平台。对于正式问题上报还是应采取提交“问题报告单”形式上报；问题咨询应通过OA或电话形式。应用管理处应用系统维护岗的负责同志应有取舍的对论坛中有共性的问题进行答复。对属于操作类的问题，须判断属于误操作，还是存在脏数据，应按问题的性质分别给出处理办法。如果发现问题属于系统中存在脏数据，应请当地问题单位及时清理。如其中数据涉及数据拥有部门（如：财务部、业管部等），应向相关部门申请，在获得书面同意后方可进行修改。同时，如果需要直接修改后台数据库中的数据，具体流程应参考运行管理流程中关于修改后台数据库中的相关规定。生产用软件系统的系统变更系统变更工作可分为下面三类类型：功能完善维护、系统缺陷修改、统计报表生成。功能完善维护指根据业务部门的需求，对系统进行的功能完善性或适应性维护；系统缺陷修改指对一些系统功能或使用上的问题所进行的修复，这些问题是由于系统设计和实现上的缺陷而引发的；统计报表生成指为了满足业务部门统计报表数据生成的需要，而进行的不包含在应用系统功能之内的数据处理工作。系统变更工作以任务形式由需求方（一般为业务部门）和维护方（一般为信息部门的应用维护组织和软件开发组织，还包括合作厂商）协作完成。系统变更过程类似软件开发，大致可分为四个阶段：任务提交和接受、任务实现、任务验收和程序下发上线。具体流程，前三个阶段参见《系统变更流程》，第四个阶段参见《程序下发流程》。因问题和紧急事件处理引发的系统变更处理，具体流程参见《问题变更流程》和《紧急变更流程》。系统变更需求只能由应用系统具体拥有部门作为需求部门提出，由具体开发应用系统的信息技术部作为维护部门接受。需求部门变更需求提出人应将变更需求整理成《内部任务书》，以部门名义提交给信息技术部，《内部任务书》在提交前应由需求部门负责人审批。维护部门由应用管理组织负责接受需求、分析需求，并提出系统变更建议，对《内部任务书》的处理意见应经过信息技术部负责人审批。应用管理组织在变更需求的分析过程中应评估并核实变更对现有运行带来的影响，并给出优先级分配的建议。上述评估结果和处理意见应做为处理意见的一部分包含于《内部任务书》中。需求部门对变更需求本身的变更，应以《需求变更书》的形式向维护部门正式提出。应用管理组织负责系统变更需求的实现，按照分配的优先级安排变更实施的先后次序，并据此产生供发布的程序，同时确保所有的变更请求都已经记录，并且能跟踪处理所有已记录的变更请求。信息技术部负责人应根据应用管理组织提供的变更情况记录审核系统变更的进度。实现过程应按照软件开发过程规定进行。系统变更过程应遵循软件开发过程相同的正式、统一的编码标准，并经过测试和正式验收才能下发和上线。系统变更过程中，应用管理组织应采取各种措施保证维护环境程序代码访问权限受到良好控制。这些措施包括：通过系统用户的授权管理，确保只有特定人员能进行系统维护工作；如果使用专用程序开发工具，只有授权人员才能使用程序开发工具（通过只有特定开发人员拥有程序开发工具）；通过对源代码的访问控制，限制只有授权人员才能获得源代码以进行系统维护；在进行自有系统的程序变更时，应建立版本控制制度确保每次在最新的代码基础上进行更改，当多名程序员同时进行更改工作时，能够进行适当协调；通过对系统日志的审阅，监督系统维护人员在系统中的操作，确认维护工作的授权；在进行自有系统的程序变更时，应严格遵循《系统变更流程》以防止或者发现源代码在完成测试到正式上线之间的非授权修改。系统变更过程中，应用管理组织应采取各种措施保证生产系统应用程序访问权限受到良好控制。这些措施包括：通过生产环境的访问控制，限制对生产环境的访问；通过物理隔离的手段，限制对生产环境的访问；通过逻辑隔离的手段，限制对生产环境的访问；对授权访问生产环境的人员进行详细记录，使用该记录对生产环境访问权限的检查，确保只有经授权人员才能访问生产环境；普通用户只能通过前台登录系统，不能通过后台（如使用生产环境操作系统的命令行）进行操作；信息技术人员不应该拥有前台应用程序的访问权限，更不应该在前台应用程序中担任实际的操作任务；从技术角度限制开发人员对生产环境中应用程序文件夹的访问权限，只有经过授权的人员对程序拥有读、写和执行的权限；禁止信息技术人员共享操作系统级别的账号。相关软件开发处室完成系统变更后，应向应用管理处提交修改的程序。应用管理处收到修改的程序后，判断是否需要通过下发补丁的形式更新程序。如问题属于暂时、仅个别单位存在且影响不大的，可先将修改程序交存在问题的单位。除因紧急情况需临时下发外，程序应按周期固定下发时间。接收相关开发处室提交的程序时，应要求其将问题跟踪单一并反馈。当生产用软件需要下发新版本，进行系统变更时，应由相关软件开发处室负责相应系统的人员以提交《发版申请表》的形式，向应用管理处负责相应系统的人员提出下发的软件的申请。同时应一并提交软件升级包、源程序、验收测试报告、升级说明等相关文档。相关软件开发处室负责相应系统的人员提交的《发版申请表》，必须由相关开发处室经理及负责相应系统的人员签字后方生效。负责应用管理的系统维护的人员检查软件开发处室负责相应系统的人员提交的资料是否完整、内容是否齐全、表示是否清楚、版本是否最新；同时，将升级包在测试机上进行安装测试，测试结束后，在《上线申请表》中出具意见，并签字确认。相关文档经检查无误，且升级包在测试机上进行安装测试通过后，应用管理负责相应系统维护的人员确定升级包的版本名称，并填写《系统上线申请表》，并提交应用管理处经理。如在检查中发现问题，则请相关处室修改后重新提交。系统维护人员将升级包上传到发版用FTP服务器之前，应取得主管领导的授权，授权以主管领导在《系统上线申请表》上的签字为准。发版升级包及发版用FTP服务器只能由系统维护人员更新，下发的升级包只能由下级公司的指定人员获取。应用维护组织应通过正式的途径向下级公司系统维护人员发出程序下发通知，通知中需列出分发途径、软件识别的方法（如程序包的名称、版本及程序包的大小）、下发时间及期限。各级公司系统维护人员应在自有系统的程序变更上线前，应严格遵照《程序下发流程》，建立足够的“回退”计划以避免升级失败的发生，并确保生产环境和生产库以及全部的相同应用系统都及时更新到最新版的程序。各级公司系统维护人员应按照《问题和应急事件处理》制度的规定，依据《问题变更流程》和《紧急变更流程》对应用系统各类问题和各级紧急事件进行处理。对于紧急事件，只能由维护部门应用管理组织按照事先明确的紧急事件定义做出判断，确定其优先级和影响程度，并启动应用系统紧急变更。紧急变更过程中应使用专设系统用户帐号。应用管理组织应对紧急事件的处理进行规范、明确的文档记录，并在紧急事件处理完成后，按照一般问题处理的要求补充正式、完整的文档。应用维护组织负责对系统变更项目的文档进行归档管理，变更过程中涉及的所有文档应至少保存三年。附则本制度由公司总部信息技术部负责解释和修订。本制度自发布之日起开始执行。系统变更流程系统变更流程描述：一、概要说明1、系统变更范围目前全系统内自有应用系统按来源可分为两类：由总公司组织开发完成的应用系统和由省公司组织开发完成的应用系统。对于上述两类已上线应用系统，均会因下面三种原因产生系统变更需求：功能完善维护业务部门由于业务发展或业务处理的需要，所产生的对系统的现有功能进行修改、完善的需求。系统缺陷修改系统设计和实现上的缺陷会引发业务操作中的异常。对系统缺陷进行修复的需求。统计报表生成业务部门统计报表数据生成的需求。所要求的统计报表数据不能够通过应用系统现有功能提供。这些报表有的只是一次性使用，有的需要经常使用。2、需求方和维护方为保证应用系统与业务管理要求的一致性，系统变更需求只能由特定的需求方形成并提出，由特定的维护方接受并处理。需求方以外的各个部门，如果形成系统变更需求，必须先提交给需求方，经采纳后再由需求方提出。信息部门如果接到未按本制度要求的途径提交的系统变更需求，应向提出方解释不能受理的原因，并就提交方式按本制度要求向提出方提供建议。三类系统变更需求的需求方和维护方，在流程描述中具体说明。二、流程描述系统变更流程按照需求类型分别以功能完善维护、系统缺陷修改和统计报表生成三个子流程进行描述，各个子流程同时适用于总公司开发系统和省公司开发系统。流程中涉及的《内部任务书》、《外部任务书》和《验收报告书》的使用细则，参见《任务书填写说明及流程说明》。=1\*GB4㈠、功能完善维护子流程功能完善维护子流程由任务提交和接受、任务实现、任务验收和程序下发四个阶段构成。1、任务提交和接受功能完善维护需求的需求方为应用系统构建时提出需求的业务部门，维护方为负责按照需求实际构建应用系统的信息部门。以总公司开发的业务系统为例，需求方是总公司业务管理部，维护方是总公司信息技术部。需求应满足一定要求。具体规范见《系统变更需求规范》。流程如下：=1\*GB3①、需求形成需求方根据业务发展或业务处理的需要，结合收集到的各级公司用户部门的要求，初步形成功能完善维护需求。经和维护方沟通后，填写《内部任务书》。=2\*GB3②、需求方（业务部门）负责人审批需求方将《内部任务书》报请部门负责人签字批准后，经指定途径提交给维护方。=3\*GB3③、需求评估维护方应用管理组织审查需求，会同软件开发组织进行需求评估，产生评估结果。=4\*GB3④、维护方（信息部门）负责人审批维护方应用管理组织将评估结果附在《内部任务书》上，报请部门负责人签字批准后，正式向软件开发组织下达任务。如果任务实现由合作厂商完成，则由维护方软件开发组织按照与合作厂商签订的技术服务合同，填写《外部任务书》，报请部门负责人签字批准后，正式向合作厂商下达系统任务。=5\*GB3⑤、任务登记为了便于追踪各个系统变更需求的状态，应用管理组织需要在任务管理系统中对接受的需求进行登记，以便统一管理和查询。软件开发组织每周对该登记表中的需求完成状态进行更新，以便信息部门负责人进行系统变更任务进度的审核。2、任务实现软件开发组织（或由软件开发组织会同合作厂商）根据《内部任务书》的需求描述，按照与软件开发流程同样的正式、统一的步骤，进行分析、设计、编码、测试，最终完成系统变更需求。需求实现过程中应严格遵照源代码管理办法，做好任务实现过程中的源代码版本控制。具体规范见《源代码访问授权管理规范》。为避免需求实现过程中对生产环境造成影响，开发和测试应在独立于生产环境的开发和测试环境中进行。具体规范见《生产环境访问权限管理规范》。3、任务验收任务验收以业务部门为主，信息部门配合完成。任务验收的依据是业务部门提交的任务需求，以及根据任务需求设计好的测试案例。测试案例和测试计划均由业务部门事先制定。任务开发测试完成后，由软件开发组织通过任务管理系统通知应用管理组织，并提供可用于验收测试的文档和程序升级包。应用管理组织作为联系人，联系业务部门组织人员按照测试计划进行验收测试。验收测试使用专门的测试环境，由应用管理组织使用软件开发组织提供的程序升级包构建，测试数据也由应用管理组织按照测试案例准备。验收测试的过程中发现问题的更改，同软件开发流程。验收测试通过后，由业务部门在《验收报告书》上出具验收结论和下发意见，并由业务部门和信息部门（由应用管理组织代表）双方签字。如果任务实现由合作厂商完成，则由维护方软件开发组织在内部任务验收完成后，根据业务部门的验收意见，结合软件开发组织对合作厂商的软件验收结果，在《外部任务书》上出具验收意见并签字。4、程序下发具体见《程序下发流程》。系统变更任务结束后，由专门人员将整个过程中产生文档的最终版本进行统一归档管理。=2\*GB4㈡、系统缺陷修改子流程对于来自业务部门的系统缺陷修改需求，系统缺陷修改子流程同功能完善维护子流程。对于来自问题处理系统的系统缺陷修改需求，系统缺陷修改子流程见《问题变更流程》和《紧急变更流程》。=3\*GB4㈢、统计报表生成子流程统计报表生成子流程基本同功能完善维护子流程，也由任务提交和接受、任务实现、任务验收和程序下发四个阶段构成。特别之处在于：1、任务提交和接受统计报表生成的需求方可以为应用系统构建时提出需求的业务部门，此时维护方为负责按照需求实际构建应用系统的信息部门。以总公司开发的业务系统为例，需求方是总公司业务管理部，维护方是总公司信息技术部。需求方也可以为使用应用系统进行实际业务处理的业务部门，此时维护方为向需求方提供运行支持的信息部门。仍以总公司开发的业务系统为例，需求方可以是省（地市）公司业务管理部，此时维护方是省（地市）公司信息技术部。2、任务实现分析：综合考虑各方面的情况（包括报表的使用频率、程序开发的复杂性、需求的紧急程度）制定技术方案，决定是进行程序开发还是通过SQL语句实现数据的抽取，并据此完成后继的设计和实施。测试：由开发人员在测试环境利用事先准备好的测试数据测试确认逻辑的正确性。3、任务验收软件开发组织将经过测试的程序或SQL语句交给应用管理组织运行，生成统计报表。应用管理组织将生成的统计报表提交给需求方，由需求方判断统计报表数据是否正确，并据此确认验收是否通过。4、程序下发如果统计报表只限本公司使用，则不进行程序或SQL语句的下发。如果统计报表有逐级汇总的要求，则下级公司要将生成的统计报表结果通过情况反馈的渠道上报给上级公司。三、相关规范与系统变更流程相关的规范有下面三类：系统变更需求规范、源代码访问授权管理规范、生产环境访问权限管理规范。1、系统变更需求规范系统变更需求是业务部门提交任务的重要组成部分，也是业务部门和信息部门验收任务完成情况的主要依据。对系统变更需求的要求如下：被认为是经过业务部门审批并提交给信息部门的正式需求有:《内部任务书》“【任务概述】”中记载的需求描述，《内部任务书》“【附加文档】”中列举的文档，《需求变更书》中记载的需求变更，《需求答疑书》中记载的信息部门提出的需求确认问题以及业务部门的回答；第一类需求（功能完善维护）和第三类需求（统计报表生成）应包含下列五类内容：业务概述、需求依据（国家法规/行业规程/公司规定/分公司个性需求/特殊处理/临时方案）、业务流程（业务域→业务过程→业务活动、业务规则、相互关系、控制要求）、信息流程（单据、报表、信息域、信息属性、相互关系、输出办法）、组织流程（相关业务人员组织结构、业务人员与相关业务之间的关系、角色分配与权限控制）；第二类需求（系统缺陷修改）应包含下列四类内容：操作过程描述、问题现象描述、问题原因分析、问题修改要求；需求变更应包含下列四类内容：原有需求、变更需求、变更依据（原需求依据变更、原需求设计错误、原流程的优化）、影响范围；需求答疑应包含下列两类内容：需求确认问题、需求确认回答；为保证业务需求的完整性和一致性，业务部门在提出需求变更或答复需求疑问的同时，应将变更内容或回答内容合并整理到需求中，与需求变更或疑问答复同时提交。2、源代码访问授权管理规范需求实现过程中，需要从以下几个方面加强源代码授权管理：通过系统用户的授权管理，确保只有特定开发人员才能进行系统维护工作；如果使用专用程序开发工具，确保只有特定开发人员才能拥有并使用程序开发工具；通过对系统日志的审阅，监督系统维护人员在系统中的操作，确认维护工作的授权；通过使用专门的版本控制软件对源代码进行访问控制，设置源代码管理人员对源代码进行专门管理，限制只有源代码管理人员对源代码有访问权限，开发人员对源代码没有访问权限，由源代码管理人员根据需要获得源代码并交给开发人员进行系统维护；使用版本控制软件，确保每次在最新的代码基础上进行更改，同时建立版本控制制度，当多名程序员同时进行更改工作时，能够进行适当协调，保证高优先级任务相关的源代码被优先修改；开发人员开发完成并通过测试后将源代码和编译后的程序提交给源代码管理人员，由其进行下发管理，以防止源代码在完成测试到正式上线之间的非授权修改。3、生产环境访问权限管理规范需求实现过程中，需要从以下几方面加强生产环境应用程序和生产数据的访问权限管理：通过生产环境的访问控制，限制对生产环境的访问；通过物理隔离的手段，限制对生产环境的访问；通过逻辑隔离的手段，限制对生产环境的访问；对授权访问生产环境的人员进行详细记录，使用该记录对生产环境访问权限的检查，确保只有经授权人员才能访问生产环境；普通用户只能通过前台登录系统，不能通过后台（如使用生产环境操作系统的命令行）进行操作。应该从技术角度进行限制，如通过在用户帐户的.profile文件中设置控制语句，在登录后强制执行应用程序，进入图形化的菜单界面，避免终端用户进入命令行模式。同时，用户登录系统后，在系统中规定闲置时间如果超过一定时间，系统将会自动终止该用户的进程；信息人员不应该拥有前台应用程序的访问权限，更不应该在前台应用程序中担任实际的操作任务；从技术角度限制开发人员对生产环境中应用程序文件夹的访问权限，只有经过授权的人员对程序拥有读、写和执行的权限；禁止信息技术人员共享操作系统级别的账号，尤其是权限比较大的账号，如Root,Informix账号等。从技术角度限制开发人员对生产环境中生产数据的访问权限，只有经过授权的人员对生产数据拥有读、写和修改的权限。程序下发流程(省公司开发系统)程序下发流程(总公司开发系统)程序下发流程描述一、概要说明按照应用系统构建方的不同，程序下发流程分为总公司开发系统的程序下发子流程和省公司开发系统的程序下发子流程。二、流程描述=1\*GB4㈠、总公司开发系统的程序下发子流程概括地讲，总公司信息技术部负责下发程序的准备工作并下发到省公司，省公司信息技术部负责将程序下发给各个地市并进行下发程序的安装指导工作，各地市公司信息技术部负责具体安装操作。下发程序移交任务开发完成并经过业务部门验收后，由信息技术部软件开发人员将程序升级包正式移交给相应应用管理人员，应用管理人员要对移交内容进行验收。应用管理人员同时从业务部门获得验收测试报告。信息技术部设立专责人员负责程序的下发和下发程序的版本管理，应用系统管理人员将获取的程序升级包交专责人员归入下发软件库。下发软件库只能由专责人员更新和访问，并对其进行版本控制。下发程序打包程序下发专责人员按照下发要求将移交的程序升级包制作成符合下发要求的下发包，由应用管理人员对其进行升级安装测试，并形成书面的测试记录。经过测试的下发程序包也由专责人员归入下发软件库。程序下发申请程序下发专责人员对程序升级包按照对应任务的优先级排序，参考业务部门的下发意见，每半月向信息技术部相关负责人提出程序下发申请，由相关负责人签字审核。提交下发申请时，需附升级安装测试记录、用户验收测试报告。程序下发程序下发专责人员将程序下发包上载到总公司专门的发版服务器。发版服务器只能由专责人员更新，对于下发包的访问和下载设置权限控制，按照实际的工作需要授予省公司信息技术部人员读取权限，防止程序扩散。获取下发程序省公司信息技术部设立专责人员负责程序的下发和下发软件的版本管理，专责人员负责监视总公司发版服务器并及时获取总公司发布的程序下发包。信息部门测试程序下发专责人员获取下发包后，通知省公司信息技术部相应应用管理人员，应用管理人员在测试环境中对程序包进行升级安装测试，并形成书面的测试记录。提出升级的关键点和注意点，为地市分公司的升级提供指导和参考意见。用户部门测试信息部门测试通过后，应用管理人员通知省公司软件使用部门对程序功能进行测试，测试前信息技术部人员需要协助软件使用部门准备详细的测试计划，测试应该在专门的测试环境中进行，记录测试内容，填写书面的测试报告。测试过程中，如果发现问题，省公司软件使用部门填写《问题报告单》提交给省公司信息技术部，寻求解决办法。用户的培训测试通过后，针对本次系统变更的内容，省公司业务部门应召集各地市业务人员对其进行培训，为用户提供书面的培训资料。根据程序下发的频率，培训每月进行一次。程序上线申请信息部门和用户部门的测试通过后，由程序下发专责人员向信息技术部相关负责人提出程序上线申请，信息技术部相关负责人与业务部门负责人共同确定上线日期，进行书面的签字审核。提交上线申请时，需附升级安装测试记录、用户验收测试报告。程序下发和通知程序下发专责人员将程序下发包放置在省公司专门的发版服务器上，下发包中还应包括提供给地市信息技术部人员的维护手册和升级说明。发版服务器只能由专责人员更新，对于下发包的访问和下载设置权限控制，按照实际的工作需要授予地市信息技术部人员读取权限，防止程序扩散。下发包放置在下载服务器上之后，省公司信息技术部专责人员程序下发人员向各地市分公司下发正式的公文通知，公文通知中应指明分发途径、软件识别方法、升级完成时间等。保证升级工作按照省公司的统一部署进行。程序上线地市分公司信息技术部指定人员登录下载服务器，将程序包下载到本地服务器，在要求的时间内，对生产环境的所有相同应用系统进行上线的实施。程序上线前，地市信息技术人员建立“回退”计划，并备份升级前的程序和数据库，以避免升级失败时，系统不能恢复到升级前的状态。上线过程中，如果发现问题，则各地市信息技术部填写《问题报告单》，并和省公司信息技术部联系，上报发现的问题，寻求解决办法。上线情况反馈地市公司上线实施完毕以后，指定人员填写《升级情况反馈表》，该表中包括升级实施人签名、升级时间、升级过程、升级结果等信息。填写完毕，提交给地市公司信息技术部负责人签字审批。然后，指定人员将《升级情况反馈表》上报到省公司信息技术部程序下发专责人员，汇报完成情况，以便于省公司信息技术部全面掌握升级情况，进行监督检查。省公司将升级情况汇总后，形成《升级情况反馈表》上报到总公司信息技术部程序下发专责人员。归档管理和定期检查地市公司信息技术部设置专责人员负责程序上线过程中文档的归档管理，每次上线完成后进行归档。省公司信息技术部设置专责人员负责程序下发过程中文档的归档管理。每三个月一次检查各地市上报的《升级情况反馈表》，同时，登录各地市的系统服务器，检查生产环境中的程序是否为最新版本，确保各地市系统版本的一致性。总公司信息技术部完成同样的归档和检查工作。但检查采取抽查方式，抽查比例为10％。=2\*GB4㈡、省公司开发系统的程序下发子流程概括地讲，省公司信息技术部负责下发程序的准备工作并下发到各个地市并进行下发程序的安装指导工作，各地市公司信息技术部负责具体安装操作。下发程序移交任务开发完成并经过业务部门验收后，由信息技术部软件开发人员将程序升级包正式移交给相应应用管理人员，应用管理人员要对移交内容进行验收。应用管理人员同时从业务部门获得验收测试报告。信息技术部设立专责人员负责程序的下发和下发程序的版本管理，应用系统管理人员将获取的程序升级包交专责人员归入下发软件库。下发软件库只能由专责人员更新和访问，并对其进行版本控制。下发程序打包程序下发专责人员按照下发要求将移交的程序升级包制作成符合下发要求的下发包，由应用管理人员对其进行升级安装测试，并形成书面的测试记录。经过测试的下发程序包也由专责人员归入下发软件库。用户的培训验收通过后，针对本次系统变更的内容，省公司业务部门应召集各地市业务人员对其进行培训，为用户提供书面的培训资料。根据程序下发的频率，培训每月进行一次。程序上线申请程序下发专责人员对程序升级包按照对应任务的优先级排序，参考业务部门的上线意见，每半月向信息技术部相关负责人提出程序上线申请，信息技术部相关负责人与业务部门负责人共同确定上线日期，进行书面的签字审核。提交上线申请时，需附升级安装测试记录、用户验收测试报告。程序下发和通知程序下发专责人员将程序下发包放置在省公司专门的发版服务器上，下发包中还应包括提供给地市信息技术部人员的维护手册和升级说明。发版服务器只能由专责人员更新，对于下发包的访问和下载设置权限控制，按照实际的工作需要授予地市信息技术部人员读取权限，防止程序扩散。下发包放置在下载服务器上之后，省公司信息技术部专责人员程序下发人员向各地市分公司下发正式的公文通知，公文通知中应指明分发途径、软件识别方法、升级完成时间等。保证升级工作按照省公司的统一部署进行。程序上线地市分公司信息技术部指定人员登录下载服务器，将程序包下载到本地服务器，在要求的时间内，对生产环境的所有相同应用系统进行上线的实施。程序上线前，地市信息技术人员建立“回退”计划，并备份升级前的程序和数据库，以避免升级失败时，系统不能恢复到升级前的状态。上线过程中，如果发现问题，则各地市信息技术部填写《问题报告单》，并和省公司信息技术部联系，上报发现的问题，寻求解决办法。上线情况反馈地市公司上线实施完毕以后，实施人员填写《升级情况反馈表》，该表中包括升级实施人签名、升级时间、升级过程、升级结果等信息。填写完毕，提交给地市公司信息技术部负责人签字审批。然后，实施人员将《升级情况反馈表》上报到省公司信息技术部程序下发专责人员，汇报完成情况，以便于省公司信息技术部全面掌握升级情况，进行监督检查。归档管理和定期检查地市公司信息技术部设置专责人员负责程序上线过程中文档的归档管理，每次上线完成后进行归档。省公司信息技术部设置专责人员负责软件下发过程中文档的归档管理。每三个月一次检查各地市上报的《升级情况反馈表》，同时，登录各地市的系统服务器，检查生产环境中的程序是否为最新版本，确保各地市系统版本的一致性。内部任务书流程外部任务书流程验收报告书流程任务书填写说明及流程说明一、简要说明任务书分为内部及外部任务书，《内部任务书》实现相关业务部门与信息技术部的内部任务提交与接受流程，《验收报告书》实现相关业务部门与信息技术部的内部任务完成与验收流程，《外部任务书》实现我部作为甲方代表与乙方的外部任务下达与接受、完成与验收流程。三类需求可以作为公司内部任务：已上线应用系统的功能完善性或适应性维护需求；已上线应用系统在业务处理过程中发现的系统缺陷修复要求；不包含在应用系统功能之内的数据抽取和统计报表数据生成等需求。包含上面三类需求的部门协作单、签报等也属于内部任务，并纳入《内部任务书》管理。由于此种形式的需求已通过相应的公文流转流程完成了业务部门的审批及提交，因此不再要求业务部门重新作为《内部任务书》提交，而是由信息技术部任务管理处室（应用管理处或规划处）代填《内部任务书》。其中“【需求部门意见】”栏填写任务来源说明（具体部门协作单、签报等的名称），“项目/部门负责人签字、日期”也由任务管理处室代填。《内部任务书》、《验收报告书》和《外部任务书》配套使用，对应留存。可以多份《内部任务书》对应一份《外部任务书》（典型情况为同时收到多份《内部任务书》，将其统一下达给合作厂商完成）。《内部任务书》头部设置了相应的项目用于记载对应的《外部任务书》编号。可以多份《外部任务书》对应一份《内部任务书》（典型情况为一份《内部任务书》的内容涉及多个应用系统，或包含多个需求，或需求复杂需要分成若干期实现）。《外部任务书》头部设置了相应的项目用于记载对应的《内部任务书》编号。《内部任务书》的编号格式为：RWSN-年份-序号，由信息技术部综合秘书在接到后统一编号；《外部任务书》的编号格式为：系统名称英文缩写-RWSW-年月-序号，由各开发处室在填写时编号。其中RWSN为内部任务书文字缩写，RWSW为外部任务书文字缩写，年份用yyyy，年月用yyyymm，序号位数3位（001-999）。《外部任务书》中开始/完成时间与工作量/金额，计划部分由甲乙双方共同评估，评估后由甲方填写；实际部分由乙方提出，经甲方审核后由乙方填写。《内部任务书》中的相应项目应与《外部任务书》保持一致。信息技术部根据任务紧急程度在规定的时间内对业务部门提交的内部任务接受意见做出反馈：普通任务一周，紧急任务三日，特急任务一日。二、内部任务书流程说明任务前期论证任务书前期论证由业务部门项目人员会同信息技术部开发处室及任务管理处室人员共同进行。通过论证，双方应基本明确业务需求，并对任务完成时间达成一致。任务形成提交业务部门根据基本明确的业务需求填写《内部任务书》的“任务提交栏”，由相关项目及部门负责人签字或审核后，将《内部任务书》（如果业务需求为单独文档，作为《内部任务书》附件）提交至信息技术部综合秘书，提交纸质材料的同时应提交电子文档。业务部门如在提交《内部任务书》后要对需求进行变更，需及时向信息技术部综合秘书了解审批情况。如果尚未提交审批，可将需求的变更形成《需求变更书》提交；否则，应作为新的任务处理。任务接收登记信息技术部综合秘书对收到的《内部任务书》进行登记编号，并根据项目性质分发到任务管理处室（应用管理处或规划处）。任务受理分派任务管理处室根据收到的任务内容，将《内部任务书》（包括需求文档附件）通过任务管理系统提交给相应的开发处室，征求会签意见。对于涉及多个开发处室的需求，可请示部门负责人指定一个开发处室作为主办处室，由主办处室负责任务实现过程中部门内的协调工作。任务需求分析开发处室根据任务管理处室提交的《内部任务书》，进行可行性分析和初步需求分析，产生可行性结论、相关运行影响评估和优先级分配意见，并提出工作量（费用）估算、实施计划安排及建议处理意见，上述分析结果作为会签意见通过任务处理系统返回任务管理处室。对于费用估算超过一定金额（规定为人民币两万元）的任务，开发处室应提交工作量－费用对照详单。如内部任务需交合作厂商完成，开发处室还应填写《外部任务书》的“任务下达栏”。填写好的《外部任务书》与处理意见同时返回任务管理处室。任务意见审批任务管理处室参考开发处室会签意见汇总形成部门处理意见，填写《内部任务书》“任务接收栏”，任务管理处室项目、处室负责人签字后，经任务管理系统报部门负责人审核并签字。如内部任务需交合作厂商完成，任务管理处室应将开发处室返回的《外部任务书》与《内部任务书》一起报审。任务反馈存档综合秘书将部门审核完毕的《内部任务书》复印件作为任务接受反馈提交需求部门留存，原件归档保存。任务登记启动任务管理处室根据部门意见对正式接受任务进行登记，并通知开发处室项目负责人。开发处室项目负责人接到通知后正式启动任务。如内部任务需交合作厂商完成，任务管理处室应将部门审核完毕的《外部任务书》交给开发处室。三、验收报告书流程说明任务验收测试验收测试由业务部门组织，按照业务部门制定的测试计划，依据任务需求和测试案例进行。信息技术部开发处室负责提供可用于验收测试的文档和程序升级包，并进行现场问题处理；任务管理处室作为联系人，同时协调开发处室构建验收测试环境。验收结论签署验收测试通过后，业务部门对信息技术部提出的任务完成情况、实际工作量和费用进行确认，确认后，由信息技术部在《验收报告书》上填写“任务完成情况栏”并双方签字；由业务部门在《验收报告书》的“任务验收情况栏”和“任务验收结论栏”上出具验收意见、验收结论和下发意见，并双方签字。签字的《验收报告书》复印件交业务部门留存，原件交综合秘书归档保存。《验收报告书》电子版通过任务管理系统提交给相应的开发处室保存。四、外部任务书流程说明任务形成提交只针对一个内部任务分成若干期实现的情况，其他情况见内部任务书流程。开发处室项目负责人根据任务内容填写《外部任务书》的“任务下达栏”。任务意见审批只针对一个内部任务分成若干期实现的情况，其他情况见内部任务书流程。开发处室将经项目负责人、处室负责人签字的《外部任务书》报部门负责人审核并签字。任务下达启动部门审核完毕的《外部任务书》，由开发处室项目负责人登记后正式下达给合作厂商。合作厂商接到任务后，填写《外部任务书》的“任务接收栏”，并据此启动任务。软件文档审查任务开发测试完成后，合作厂商提交文档（技术文档、测试文档和使用文档）和程序升级包，开发处室进行审查。审查过的文档和程序升级包，由开发处室作为内部任务验收的基础提交给任务管理处室。验收结论签署内部任务验收完成后，开发处室对合作厂商提出的任务完成情况、实际工作量/费用进行确认，确认后，由合作厂商填写《外部任务书》的“任务完成情况栏”并双方签字；开发处室根据内部任务验收报告上业务部门的验收结论，在《外部任务书》的“任务验收情况栏”出具验收结论，并双方签字。签字的《外部任务书》原件一份交合作厂商，一份交综合秘书归档保存。问题变更流程一、概要说明问题处理系统中记录的应用系统一般问题，如果经问题处理人员分析属于系统缺陷，则采用本流程作为具体问题处理方案进行处理。二、流程描述类似系统变更流程的系统缺陷修改子流程，也由任务提交和接受、任务实现、任务验收和程序下发上线四个阶段构成。1、任务提交和接受需求方和维护方均由负责按照需求实际构建应用系统的信息部门担当。应用管理组织在其中同时担当需求方和维护方，软件开发组织在其中担当维护方。以公司总部开发的业务系统为例，需求方是公司总部信息技术部应用管理处，维护方是公司总部信息技术部应用管理处和各软件开发处。流程如下：=1\*GB3①、需求形成应用管理组织对问题处理系统中受理的各级公司报告的问题进行初步分析，并向问题报告方补充了解情况，将定位为系统缺陷的问题整理成《BUG管理表》。=2\*GB3②、需求方（应用管理组织）负责人审批应用管理组织将《BUG管理表》报请组织负责人签字批准后，经问题处理系统提交给维护方。=3\*GB3③、需求评估软件开发组织对收到的《BUG管理表》进行分析，制定修改方案、计划。=4\*GB3④、维护方（软件开发组织）负责人审批软件开发组织将修改方案、计划附在《BUG管理表》上，报请组织负责人签字批准后，回复应用管理组织。如果问题修改需要由合作厂商完成，则由软件开发组织按照与合作厂商签订的技术服务合同，填写《外部任务书》，报请部门负责人签字批准后，正式向合作厂商下达系统任务。=5\*GB3⑤、问题登记借助任务处理系统，应用管理组织对软件开发组织已列入计划的问题进行登记，软件开发组织每周对该登记表中的问题完成状态进行更新。2、任务实现同系统变更流程的系统缺陷修改子流程。3、任务验收基本同同系统变更流程的系统缺陷修改子流程。不同之处在于：任务验收以应用管理组织为主，软件开发组织配合完成。测试案例和测试计划均由应用管理组织事先制定。应用管理组织还可选择由问题报告方进行验收测试，以问题报告方的反馈作为测试结果。验收测试通过后，由应用维护组织出具验收结论和下发意见，并在验收报告上签字。4、程序下发同系统变更流程的系统缺陷修改子流程紧急变更流程紧急变更流程描述一、概要说明问题处理系统中记录的应用系统紧急事件，问题处理人员采用本流程作为具体问题处理方案进行处理。紧急事件变更处理过程中的上报、请示、批准等可以通过电话或电子邮件的形式进行，待问题解决后再按照一般系统变更流程补办各类文档和领导审批记录。二、流程描述1、紧急事件的报告地市公司用户部门人员或其他人员发现系统异常，导致业务处理无法正常进行，必须迅速处理解决时，问题发现人将问题报告给地市公司信息技术部专责人员。地市公司信息技术部专责人员根据问题信息，进行问题的初步诊断，如有可能，对问题原因进行分析定位，并给出解决问题的建议，同时尽快向省公司信息技术部相关负责人（部门经理或应用系统管理人员）汇报。如为总公司开发系统的紧急问题，紧急问题将由省公司信息技术部最终上报到总公司信息技术部。2、紧急事件变更启动总/省公司信息技术部相关负责人接到紧急问题上报后，指定紧急事件变更任务负责人（通常为应用系统管理人员），负责解决本次的紧急修改问题。紧急事件变更任务负责人及时与紧急问题上报公司的信息技术部人员进行讨论和交流，了解情况，并最终判定是否属于紧急事件。确定属于紧急事件后，由紧急修改任务负责人启动紧急事件变更流程，并根据其重要性和紧迫性分配优先权，组织人员采取相应的处理流程。否则，通知上报公司的信息技术部人员，请其按照一般问题变更流程处理，并将结果报告给总/省公司信息技术部相关负责人。3、紧急事件变更处理紧急事件变更任务负责人组织人员进行紧急事件变更处理。紧急事件变更流程的变更处理同一般问题变更流程，包括分析、设计、实施、测试、验收，但需使用专设系统用户账号进行紧急事件变更，并由专人进行明确的紧急事件变更文档记录。4、紧急事件变更程序下发/上线紧急事件变更任务负责人组织完成变更处理后，尽快向总/省公司信息技术部相关负责人报告，并提出下发/上线申请，经同意后，进行程序下发/上线。紧急事件变更流程的程序下发/上线同一般系统变更流程。5、补办文档和领导审批记录紧急问题得到妥善解决后，各级公司需要分别补办各类文档和领导审批记录，具体需要补办的内容包括以下：问题发现人填写的紧急问题变更申请，其中包含问题发现人对问题的描述。问题发现人所在部门的负责人对申请的审批。总/省公司信息技术部相关负责人（部门经理或相关岗位负责人）对需求的审批和任务分派。开发人员书面的设计方案和总/省公司信息技术部相关负责人对设计方案的审批。用户部门/信息部门的测试记录和签字确认的测试结果。程序下发/上线专责人员填写的下发/上线申请和总/省公司信息技术部相关负责人的审批。6、文档整理归档按照一般问题系统变更流程的要求，各级公司将紧急事件变更整个过程中的各类文档进行统一归档管理。内部任务书内部任务书中国人寿保险股份有限公司需求部门任务书编号格式：RWSN-年份-序号外部任务书编号对应的外部任务书编号，外部任务书下达后补录系统名称系统名称英文缩写系统版本任务提交栏*由业务部门填写*任务名称建议开始时间建议完成时间任务紧急程度FORMCHECKBOX普通FORMCHECKBOX紧急FORMCHECKBOX特急【任务概述】：*如包含多项内容，按顺序列出*【附加文档】：*由双方确认的需求说明书、变更说明书或系统问题报告单*【需求部门意见】：项目负责人签字：日期：部门负责人签字：日期：

任务接收栏*由信息技术部填写*任务性质FORMCHECKBOXA:开发FORMCHECKBOXB:改正性维护（识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用）FORMCHECKBOXC:适应性维护（因外部环境或数据环境的变化引发的修改）FORMCHECKBOXD:完善性维护（因用户对软件功能提出新的功能和性能需求引发的修改）FORMCHECKBOXE:其他（上述以外的修正）计划开始时间计划完成时间处理优先级FORMCHECKBOX排队FORMCHECKBOX优先FORMCHECKBOX紧急任务实现方式FORMCHECKBOX自行开发FORMCHECKBOX合作开发预计工作量人天，合人月本次任务计划税前开发费用预估（含报酬）*注明小写金额和大写金额*￥元，（大写）【运行影响评估】：*任务实现对现有系统运行性能和功能等方面带来的影响评估*【信息技术部意见】：任务管理处室项目负责人签字：日期：任务管理处室负责人签字：日期：部门负责人签字：日期：外部任务书外部任务书甲方（委托方）中国人寿保险股份有限公司乙方（受托方）任务书编号格式：系统名称英文缩写-RWSW-年月-序号内部任务书编号对应的内部任务书编号系统名称系统名称英文缩写系统版本任务下达栏*由甲方填写*任务名称任务性质FORMCHECKBOXA:开发FORMCHECKBOXB:改正性维护（识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用）FORMCHECKBOXC:适应性维护（因外部环境或数据环境的变化引发的修改）FORMCHECKBOXD:完善性维护（因用户对软件功能提出新的功能和性能需求引发的修改）FORMCHECKBOXE:其他（上述以外的修正）计划开始时间计划完成时间处理优先级FORMCHECKBOX排队FORMCHECKBOX优先FORMCHECKBOX紧急预计工作量人天，合人月本次任务计划税前开发费用预估（含报酬）*注明小写金额和大写金额*￥元，（大写）【任务概述】：*如包含多项内容，按顺序列出*【附加文档】：*由双方确认的需求规格说明书、变更说明或系统问题报告单*【甲方意见】：开发处室项目负责人签字：日期：开发处室负责人签字：日期：部门负责人签字：日期：

任务接收栏*由乙方填写*【乙方意见】：项目负责人签字：日期：负责人签字：日期：任务完成情况栏*由乙方填写，双方签字确认*实际开始时间实际完成时间实际工作量人天，合人月本次任务实际税前开发费用（含报酬）*注明小写金额和大写金额*￥元，（大写）【完成情况】：*由乙方简要概述任务完成情况*【提交文档】：*由乙方提交的技术文档、测试文档、使用文档与程序代码等*甲方开发处室项目负责人签字：乙方项目负责人签字：日期：日期：任务验收情况栏*由甲方填写，双方签字确认*【验收结论】：*由甲方根据验收报告出具验收结论*甲方开发处室项目负责人签字：乙方项目负责人签字：日期：日期：甲方开发处室负责人签字：乙方负责人签字：日期：日期：注：该表格一式两份，甲乙双方各执一份。

需求变更书需求变更书中国人寿保险股份有限公司需求部门内部任务书编号对应的内部任务书编号需求变更书序号需求变更书顺序号系统名称系统名称英文缩写系统版本需求变更栏*由业务部门填写*任务名称变更依据FORMCHECKBOX原需求依据变更FORMCHECKBOX原需求设计错误FORMCHECKBOX原流程的优化【原有需求】：*变更前的需求*【需求变更】：*变更后的需求*【影响范围】：*业务影响范围*【附加文档】：*整合了变更需求的需求说明书*项目负责人签字：日期：

验收报告书验收报告书中国人寿保险股份有限公司需求部门对应任务书编号对应的内部任务书编号系统名称系统名称英文缩写系统版本任务完成情况栏*由信息技术部根据任务完成实际情况填写*任务名称实际开始时间实际完成时间实际工作量人天，合人月本次任务实际税前开发费用（含报酬）*