生产用软件维护管理制度

期望帮到您！期望帮到您！欢送下载，精选文档欢送下载，精选文档生产用软件维护治理制度第一节总则第一条第一条其次条第三条第四条第五条

〔以下简称应用系统〕运行支持及系统变更工作。本制度所指的软件开发组织，在公司总部层面为信息技术部各软位。其次节生产用软件系统的运行支持运行支持工作可分为下面两种类型：运行维护和技术支持。运行〔批作业〕运行、数据库备份、数据清理等日常工作；技术支持指供给系统使用、技术学问上的帮助。生产用软件系统的运行维护工作由各级公司信息部门应用维护组司用户部门和下级公司信息部门应用治理组织供给。应用治理的主要职责是：处理总部各部门和分公司对目前已上线以解决。技术询问指为通过、电子邮件、技术论坛等形式为分公司及总公司相关部门供给关于应用系统的使用及维护等方面的技术支第六条第七条第八条第九条第十条第十一条第十二条

为便利治理，提高效劳效率，应制定默认处理制度。即要求回复的工作或问题，在默认的时间内未接到回复的按默认方法处理。负责处理具体应用治理的人员应每月出具问题报告，统计汇总、接收问题，供给询问等工作中发生的文档应妥当保存，纸质文档2年，电子文档每年以CDR进展统一刻录，保存时间5年。要求各级单位以问题报告单的形式报告应用系统消灭的问题。上间为准。问题报告单位应对其反映的问题做出初步定位。问题报告单位填写问题报告单应标准，并具体描述问题消灭时的状况、当时的环境以及错误提示信息等一切有助于准确定位问题的信息。同时，应完整填写上报人信息及联系方式〔以便利联络。对于不符合要求的问题报告单应返回问题报告单位重填写。接到用户通过、OA提出的询问应尽量赐予对方满足的解答。、OA提出的询问不视为正式的问题上报。论坛主要作为供各层信息技术人员沟通阅历的平台。对于正式问题上报还是应实行提交“问题报告单”形式上报；问题询问应通OA或形式。应用治理处应用系统维护岗的负责同志应有取舍的对论坛中有共性的问题进展答复。对属于操作类的问题，须推断属于误操作，还是存在脏数据，应按问题的性质分别给出处理方法。假设觉察问题属于系统中存在脏数据，应请当地问题单位准时清理。如其中数据涉及数据拥有部门〔如：财务部、业管部等同意前方可进展修改。同时，假设需要直接修改后台数据库中的数据，具体流程应参考运行治理流程中关于修改后台数据库中的相关规定。第三节生产用软件系统的系统变更第十四条第十五条第十六条第十七条

系统变更工作可分为下面三类类型：功能完善维护、系统缺陷修据处理工作。系统变更工作以任务形式由需求方〔一般为业务部门〕和维护方〔一般为信息部门的应用维护组织和软件开发组织，还包括合作厂商〕协作完成。系统变更过程类似软件开发，大致可分为四个阶段：任务提交和承受、任务实现、任务验收和程序下发上线。因问题和紧急大事处理引发的系统变更处理，具体流程参见《问系统变更需求只能由应用系统具体拥有部门作为需求部门提出，由具体开发应用系统的信息技术部作为维护部门承受。需求部门审批。维护部门由应用治理组织负责承受需求、分析需求，并提出系统变更建议，对《内部任务书》的处理意见应经过信息技术部负责人审批。理意见应做为处理意见的一局部包含于《内部任务书》中。第十九条其次十条其次十二条其次十三条

维护部门正式提出。应用治理组织负责系统变更需求的实现，依据安排的优先级安排变更实施的先后次序，并据此产生供公布的程序，同时确保全部信息技术部负责人应依据应用治理组织供给的变更状况记录审核系统变更的进度。实现过程应依据软件开发过程规定进展。系统变更过程应遵循软收才能下发和上线。系统变更过程中，应用治理组织应实行各种措施保证维护环境程序代码访问权限受到良好把握。这些措施包括：通过系统用户的授权治理，确保只有特定人员能进展系统维护工作；假设使用专用程序开发工具，只有授权人员才能使用程序开发工具〔通过只有特定开发人员拥有程序开发工具限制只有授权人员才能获得源代码以进展系统维护；在进展自有系统的程序变更时，应建立版本把握制度确保每次在最的代码根底上进展更改，当多名程序员同时进展更改工作时，能够进展适当协调；通过对系统日志的批阅，监视系统维护人员在系统中的操作，确认维护工作的授权；在进展自有系统的程序变更时，应严格遵循《系统变更流程》以防止或者觉察源代码在完成测试到正式上线之间的非授权修改。系统变更过程中，应用治理组织应实行各种措施保证生产系统应用程序访问权限受到良好把握。这些措施包括：通过生产环境的访问把握，限制对生产环境的访问；通过物理隔离的手段，限制对生产环境的访问；通过规律隔离的手段，限制对生产环境的访问；对授权访问生产环境的人员进展具体记录，使用该记录对生一般用户只能通过前台登录系统，不能通过后台〔如使用生产环〕进展操作；信息技术人员不应当拥有前台限；制止信息技术人员共享操作系统级别的账号。其次十四条相关软件开发处室完成系统变更后，应向应用治理处提交修改的程序时，应要求其将问题跟踪单一并反响。

当生产用软件需要下发版本，进展系统变更时，应由相关软件开发处室负责相应系统的人员以提交《发版申请表》的形式，向应用治理处负责相应系统的人员提出下发的软件的申请。同时应一并提交软件升级包、源程序、验收测试报告、升级说明等相关文档。相关软件开发处室负责相应系统的人员提交的《发版申请效。负责应用治理的系统维护的人员检查软件开发处室负责相应系统后，在《上线申请表》中出具意见，并签字确认。应用治理负责相应系统维护的人员确定升级包的版本名称，并填问题，则请相关处室修改后重提交。系统维护人员将升级包上传到发版用FTP效劳器之前，应取得主管领导的授权，授权以主管领导在《系统上线申请表》上的签字下发的升级包只能由下级公司的指定人员猎取。其次十九条应用维护组织应通过正式的途径向下级公司系统维护人员发出程〔如程序包的名称、版本及程序包的大小、下发时间及期限。第三十条

各级公司系统维护人员应在自有系统的程序变更上线前，应严格的发生，并确保生产环境和生产库以及全部的一样应用系统都准时更到最版的程序。各级公司系统维护人员应依据《问题和应急大事处理》制度的规题处理的要求补充正式、完整的文档。应用维护组织负责对系统变更工程的文档进展归档治理，变更过程中涉及的全部文档应至少保存三年。第四节附则本制度自公布之日起开头执行。期望帮到您！附件一 系统变更流程系统变更流程方系统变更流程方〕内部任务书验收报告书求门需部统务系业用〔应开头任务书》任务书》任务书》收测试方〕护门维部统息求系信见任务书》登记实现测试环境用〔应任务治理表期望帮到您！期望帮到您！欢送下载，精选文档欢送下载，精选文档一、概要说明1、系统变更范围目前全系统内自有应用系统按来源可分为两类系统变更需求：功能完善维护的需求。系统缺陷修改系统设计和实现上的缺陷会引发业务操作中的特别。对系统缺陷进展修复的需求。统计报表生成能供给。这些报表有的只是一次性使用，有的需要常常使用。2、需求方和维护方出，由特定的维护方承受并处理。需求方提出。信息部门假设接到未按本制度要求的途径提交的系统变更需求理的缘由，并就提交方式按本制度要求向提出方供给建议。三类系统变更需求的需求方和维护方，在流程描述中具体说明。二、流程描述系统变更流程依据需求类型分别以功能完善维护、系统缺陷修改和统计报表生成三个子流程进展描述，各个子流程同时适用于总公司开发系统和省公司开发系统。流程中涉及的《内部任务书务书填写说明及流程说明㈠、功能完善维护子流程功能完善维护子流程由任务提交和承受1、任务提交和承受功能完善维护需求的需求方为应用系统构建时提出需求的业务部门需求应满足确定要求。具体标准见《系统变更需求标准流程如下：①、需求形成需求方依据业务进展或业务处理的需要，结合收集到的各级公司用户部门的要求，初步形成功能完善维护需求。经和维护方沟通后，填写《内部任务书②、需求方〔业务部门〕负责人审批需求方将《内部任务书》报请部门负责人签字批准后，经指定途径提交给维护方。③、需求评估维护方应用治理组织审查需求，会同软件开发组织进展需求评估，产生评估结果。④、维护方〔信息部门〕负责人审批维护方应用治理组织将评估结果附在《内部任务书》上，报请部门负责人签字批准后，正式向软件开发组织下达任务。假设任务实现由合作厂商完成，则由维护方软件开发组织依据与合作厂商签订的技术效劳合同，填写《外部任务书务。⑤、任务登记为了便于追踪各个系统变更需求的状态，应用治理组织需要在任务治理系统中对承受的需求进展登记，以便统一治理和查询。软件开发组织每周对该登记表中的需求完成状态进展更统变更任务进度的审核。2、任务实现软件开发组织〔或由软件开发组织会同合作厂商〕依据《内部任务书》的需求描述，依据与软件开发流程同样的正式、统一的步骤，进展分析、设计、编码、测试，最终完成系统变更需求。需求实现过程中应严格遵照源代码治理方法，做好任务实现过程中的源代码版本把握。具体标准见《源代码访问授权治理标准为避开需求实现过程中对生产环境造成影响测试环境中进展。具体标准见《生产环境访问权限治理标准3、任务验收需求，以及依据任务需求设计好的测试案例。测试案例和测试打算均由业务部门事先制定。供给的程序升级包构建，测试数据也由应用治理组织依据测试案例预备。验收测试的过程中觉察问题的更改，同软件开发流程。验收测试通过后，由业务部门在《验收报告书》上出具验收结论和下发意见，并由业务部门和信息部门〔由应用治理组织代表〕双方签字。业务部门的验收意见，结合软件开发组织对合作厂商的软件验收结果，在《外部任务书》上出具验收意见并签字。4、程序下发具体见《程序下发流程系统变更任务完毕后，由特地人员将整个过程中产生文档的最终版本进展统一归档治理。㈡、系统缺陷修改子流程对于来自业务部门的系统缺陷修改需求，系统缺陷修改子流程同功能完善维护子流程。对于来自问题处理系统的系统缺陷修改需求，系统缺陷修改子流程见《问题变更流程》㈢、统计报表生成子流程务验收和程序下发四个阶段构成。特别之处在于：1、任务提交和承受统计报表生成的需求方可以为应用系统构建时提出需求的业务部门务治理部，维护方是总公司信息技术部。需求方也可以为使用应用系统进展实际业务处理的业务部门供运行支持的信息部门。仍以总公司开发的业务系统为例，需求方可以是省〔地市〕公司业务治理部，此时维护方是省〔地市〕公司信息技术部。2、任务实现分析：综合考虑各方面的状况〔包括报表的使用频率、程序开发的简洁性、需求的紧急程度〕制定技术方案，打算是进展程序开发还是通过SQL语句实现数据的抽取，并据此完成后继的设计和实施。测试：由开发人员在测试环境利用事先预备好的测试数据测试确认规律的正确性。3、任务验收软件开发组织将经过测试的程序或SQL语句交给应用治理组织运行，生成统计报表。此确认验收是否通过。4、程序下发假设统计报表只限本公司使用，则不进展程序或SQL语句的下发。渠道上报给上级公司。三、相关标准与系统变更流程相关的标准有下面三类生产环境访问权限治理标准。1、系统变更需求标准系统变更需求是业务部门提交任务的重要组成局部完成状况的主要依据。对系统变更需求的要求如下：被认为是经过业务部门审批并提交给信息部门的正式需求有:变更书》中记载的需求变更题以及业务部门的答复；〔功能完善维护〔统计报表生成应包含以下五类内容：业务概述、需求依据〔国家法规/行业规程/公司规定/分公司共性需求/特别处理/临时方案、业务流程〔业务域→业务过程→业务活动、业务规章、相互关系、把握要求、信息流程〔单据、报表、信息域、信息属性、相互关系、输出方法〕组织流程〔把握；〔系统缺陷修改问题缘由分析、问题修改要求；〔原需求依据变更、原需求设计错误、原流程的优化、影响范围；需求答疑应包含以下两类内容：需求确认问题、需求确认答复；2、源代码访问授权治理标准需求实现过程中，需要从以下几个方面加强源代码授权治理：通过系统用户的授权治理，确保只有特定开发人员才能进展系统维护工作；假设使用专用程序开发工具，确保只有特定开发人员才能拥有并使用程序开发工具；通过使用特地的版本把握软件对源代码进展访问把握维护；关的源代码被优先修改；开发人员开发完成并通过测试后将源代码和编译后的程序提交给源代码治理人员，由其进展下发治理，以防止源代码在完成测试到正式上线之间的非授权修改。3、生产环境访问权限治理标准需求实现过程中，需要从以下几方面加强生产环境应用程序和生产数据的访问权限治理：通过生产环境的访问把握，限制对生产环境的访问；通过物理隔离的手段，限制对生产环境的访问；通过规律隔离的手段，限制对生产环境的访问；对授权访问生产环境的人员进展具体记录，使用该记录对生产环境访问权限的检查，确保只有经授权人员才能访问生产环境；〔如使用生产环境操作系统的命令行〕进展操作。应当从技术角度进展限制，如通过在用户帐户的.profile文件中设间，系统将会自动终止该用户的进程；信息人员不应当拥有前台应用程序的访问权限际的操作任务；从技术角度限制开发人员对生产环境中应用程序文件夹的访问权限的人员对程序拥有读、写和执行的权限；制止信息技术人员共享操作系统级别的账号，尤其是权限比较大的账号，如Root,Informix账号等。从技术角度限制开发人员对生产环境中生产数据的访问权限对生产数据拥有读、写和修改的权限。期望帮到您！期望帮到您！程序下发流程〔省公司开发系统〕上线申请表用户 安装测试报告 测试记录部程序下发流程〔省公司开发系统〕上线申请表用户 安装测试报告 测试记录部司术公技省息信开头开发人员移交通过用户部门验收的系统升级包应用治理人员进展程序升级包移交验收程序下发专责人员将程序升级包入库程序下发专责人员制作下发包应用治理人员对下发包进展安装测试程序下发专责人员将下发包入库程序下发专责人员人员提交上线申请信息部门负责人审批上线申请程序下员发用户测试报告下发软件库安装测试记录下发软件库部户司用公统门省系用应用户部门组织对操作人员培训指定人员猎取下发包指定人员制定升级“回退”打算指定人员备份当前程序和数据库指定人员在生产机上做上线实施升级中是否觉察否指定人面升级司部公术是市技地息升级“回退”打算问题报告单升级反响信上报省公司信息部门进展处理欢送下载，精选文档期望帮到您！期望帮到您！程序下发流程〔总公司开发系统〕部开头司术的系统升级包交验收程序下发流程〔总公司开发系统〕部开头司术的系统升级包交验收入库员制作下发包测试审批下发申请员公布下发包公技总息信用户安装下发软件库安装下发软件库下发用户安装上线用户安装司术部公技省息信A发包试审批下发申请员公布下发包门司户部进展功能测试测试中是否觉察软件问题?否操作人员培训审批上线申请公用省统是系用应测试打算用户问题报告单部门进展处理发包升级中是否觉察软件问题?否司部公术市技是地息升级状况信打算问题报告单反响表部门进展处理欢送下载，精选文档期望帮到您！期望帮到您！欢送下载，精选文档欢送下载，精选文档程序下发流程描述公司开发系统的程序下发子流程。二、流程描述㈠、总公司开发系统的程序下发子流程术部负责将程序下发给各个地市并进展下发程序的安装指导工作责具体安装操作。下发程序移交门获得验收测试报告。信息技术部设立专责人员负责程序的下发和下发程序的版本治理对其进展版本把握。下发程序打包程序下发专责人员依据下发要求将移交的程序升级包制作成符合下发要求的下发包专责人员归入下发软件库。程序下发申请程序下发专责人员对程序升级包依据对应任务的优先级排序，参考业务部门的下发意申请时，需附升级安装测试记录、用户验收测试报告。程序下发程序下发专责人员将程序下发包上载到总公司特地的发版效劳器技术部人员读取权限，防止程序集中。猎取下发程序省公司信息技术部设立专责人员负责程序的下发和下发软件的版本治理监视总公司发版效劳器并准时猎取总公司公布的程序下发包。信息部门测试和留意点，为地市分公司的升级供给指导和参考意见。用户部门测试试前信息技术部人员需要帮助软件使用部门预备具体的测试打算境中进展，记录测试内容，填写书面的测试报告。测试过程中，假设觉察问题，省公司软件使用部门填写《问题报告单》提交给省公司信息技术部，寻求解决方法。用户的培训培训，为用户供给书面的培训资料。依据程序下发的频率，培训每月进展一次。程序上线申请字审核。提交上线申请时，需附升级安装测试记录、用户验收测试报告。程序下发和通知程序下发专责人员将程序下发包放置在省公司特地的发版效劳器上下发包的访问和下载设置权限把握，依据实际的工作需要授予地市信息技术部人员读取权限，防止程序集中。公司下发正式的公文通知，公文通知中应指明分发途径、软件识别方法、升级完成时间等。保证升级工作依据省公司的统一部署进展。程序上线的时间内，对生产环境的全部一样应用系统进展上线的实施。程序上线前，地市信息技术人员建立“回退”打算，并备份升级前的程序和数据库，以避开升级失败时，系统不能恢复到升级前的状态。上线过程中，假设觉察问题，则各地市信息技术部填写《问题报告单息技术部联系，上报觉察的问题，寻求解决方法。上线状况反响地市公司上线实施完毕以后，指定人员填写《升级状况反响表人签名、升级时间、升级过程、升级结果等信息。填写完毕，提交给地市公司信息技术部负责人签字审批。然后，指定人员将《升级状况反响表》上报到省公司信息技术部程序下发专责人员，汇报完成状况，以便于省公司信息技术部全面把握升级状况，进展监视检查。专责人员。归档治理和定期检查地市公司信息技术部设置专责人员负责程序上线过程中文档的归档治理后进展归档。省公司信息技术部设置专责人员负责程序下发过程中文档的归档治理查各地市上报的《升级状况反响表程序是否为最版本，确保各地市系统版本的全都性。总公司信息技术部完成同样的归档和检查工作。但检查实行抽查方式，抽查比例为10％。㈡、省公司开发系统的程序下发子流程序的安装指导工作，各地市公司信息技术部负责具体安装操作。下发程序移交门获得验收测试报告。信息技术部设立专责人员负责程序的下发和下发程序的版本治理对其进展版本把握。下发程序打包程序下发专责人员依据下发要求将移交的程序升级包制作成符合下发要求的下发包专责人员归入下发软件库。用户的培训培训，为用户供给书面的培训资料。依据程序下发的频率，培训每月进展一次。程序上线申请程序下发专责人员对程序升级包依据对应任务的优先级排序，参考业务部门的上线意用户验收测试报告。程序下发和通知程序下发专责人员将程序下发包放置在省公司特地的发版效劳器上下发包的访问和下载设置权限把握，依据实际的工作需要授予地市信息技术部人员读取权限，防止程序集中。公司下发正式的公文通知，公文通知中应指明分发途径、软件识别方法、升级完成时间等。保证升级工作依据省公司的统一部署进展。程序上线的时间内，对生产环境的全部一样应用系统进展上线的实施。程序上线前，地市信息技术人员建立“回退”打算，并备份升级前的程序和数据库，以避开升级失败时，系统不能恢复到升级前的状态。上线过程中，假设觉察问题，则各地市信息技术部填写《问题报告单息技术部联系，上报觉察的问题，寻求解决方法。上线状况反响地市公司上线实施完毕以后，实施人员填写《升级状况反响表人签名、升级时间、升级过程、升级结果等信息。填写完毕，提交给地市公司信息技术部负责人签字审批。然后，实施人员将《升级状况反响表》上报到省公司信息技术部程序下发专责人员，汇报完成状况，以便于省公司信息技术部全面把握升级状况，进展监视检查。归档治理和定期检查地市公司信息技术部设置专责人员负责程序上线过程中文档的归档治理后进展归档。省公司信息技术部设置专责人员负责软件下发过程中文档的归档治理查各地市上报的《升级状况反响表程序是否为最版本，确保各地市系统版本的全都性。期望帮到您！期望帮到您！内部任务书流程门开头内部任务书流程门开头完毕部务业各需求前期论证工程负责人拟制《内部任务书》部门负责人审批《内部任务书》提交双方批准的复印件保存部书术秘技合息综接收、登记双方批准的复印件反响双方批准的《内部任务书》信原件归档部处术理技管批准的息用信应意见归纳整理《内部任务书》提交审批任务登记移交部处术发技开息各可行性分析估算工作量、费用拟制《外部任务书》启动任务信统系商用发1.0应开各估算协商部人术责技负息门信部《内部任务书》批准欢送下载，精选文档期望帮到您！期望帮到您！外部任务书流程门部外部任务书流程门部务业任务验收测试各部处术理技管息用信应部开头1.0术处技发息开信各初步需求分析估算工作量、费用拟制《外部任务书》提交审批登记、下达程序包《外部任务统系商用发应开进展工作量、费用估算协商承受、实现程序包双方签字《外部任务各原件保部人术责技负息门批准信部部书术秘技合双方签字息综《外部任务信原件归欢送下载，精选文档期望帮到您！期望帮到您！验收报告书流程门部务业各组织实施测试验收验收报告书流程门部务业各组织实施测试验收预先觉察问题？签字确认否 任务完成状况填写并签署双方部处术理技管息用信应是填写并签署任务完成状况联系测试验收进展问题治理签字确认部处术发技开息各开头程序包进展问题处理信双方签字的电子版保存部书术双方技秘息合信综双方《测试原件欢送下载，精选文档期望帮到您！期望帮到您！欢送下载，精选文档欢送下载，精选文档任务书填写说明及流程说明一、简要说明1、任务书分为内部及外部任务书任务提交与承受流程与验收流程成与验收流程。2、三类需求可以作为公司内部任务：已上线应用系统的功能完善性或适应性维护需求；已上线应用系统在业务处理过程中觉察的系统缺陷修复要求；不包含在应用系统功能之内的数据抽取和统计报表数据生成等需求。3、包含上面三类需求的部门协作单、签报等也属于内部任务，并纳入《内部任务书》管理。由于此种形式的需求已通过相应的公文流转流程完成了业务部门的审批及提交，因此不再要求业务部门重作为《内部任务书》提交，而是由信息技术部任务治理处室〔应用治理处或规划处〕代填《内部任务书来源说明〔具体部门协作单、签报等的名称务治理处室代填。4、5、可以多份《内部任务书》对应一份《外部任务书〔典型状况为同时收到多份《内部任载对应的《外部任务书》编号。6、可以多份《外部任务书》对应一份《内部任务书〔典型状况为一份《内部任务书》的内容涉及多个应用系统，或包含多个需求，或需求简洁需要分成假设干期实现任务书》头部设置了相应的工程用于记载对应的《内部任务书》编号。7、《内部任务书》的编号格式为：RWSN-年份-序号，由信息技术部综合秘书在接到后统-RWSW-年月-序号，由各开RWSN为内部任务书文字缩写，RWSW为外部任务书文字缩写，年份用yyy，年月用yyyym，序号位数3位〔001-99。8、《外部任务书》中开头/完成时间与工作量/金额，打算局部由甲乙双方共同评估，评估后由甲方填写；实际局部由乙方提出，经甲方审核后由乙方填写相应工程应与《外部任务书》保持全都。9、信息技术部依据任务紧急程度在规定的时间内对业务部门提交的内部任务承受意见做出反响：一般任务一周，紧急任务三日，特急任务一日。二、内部任务书流程说明1、任务前期论证任务书前期论证由业务部门工程人员会同信息技术部开发处室及任务治理处室人员共同进展。通过论证，双方应根本明确业务需求，并对任务完成时间达成全都。2、任务形成提交业务部门依据根本明确的业务需求填写《内部任务书》的“任务提交栏及部门负责人签字或审核后，将《内部任务书〔假设业务需求为单独文档，作为《内部任务书》附件〕提交至信息技术部综合秘书，提交纸质材料的同时应提交电子文档。业务部门如在提交《内部任务书》后要对需求进展变更，需准时向信息技术部综合秘书了解审批状况。假设尚未提交审批，可将需求的变更形成《需求变更书》提交；否则，应作为的任务处理。3、任务接收登记信息技术部综合秘书对收到的《内部任务书》进展登记编号，并依据工程性质分发到任务治理处室〔应用治理处或规划处。4、任务受理分派任务治理处室依据收到的任务内容，将《内部任务书〔包括需求文档附件〕通过任务治理系统提交给相应的开发处室，征求会签意见。对于涉及多个开发处室的需求，可请示部门负责人指定一个开发处室作为主办处室，由主办处室负责任务实现过程中部门内的协调工作。5、任务需求分析开发处室依据任务治理处室提交的《内部任务书产生可行性结论、相关运行影响评估和优先级安排意见，并提出工作量〔费用〕估算、实施打算安排及建议处理意见，上述分析结果作为会签意见通过任务处理系统返回任务治理处室。对于费用估算超过确定金额〔规定为人民币两万元〕的任务，开发处室应提交工作量－费用比照详单。如内部任务需交合作厂商完成，开发处室还应填写《外部任务书》的“任务下达栏填写好的《外部任务书》与处理意见同时返回任务治理处室。6、任务意见审批任务治理处室参考开发处室会签意见汇总形成部门处理意见，填写《内部任务书核并签字。如内部任务需交合作厂商完成，任务治理处室应将开发处室返回的《外部任务书》与《内部任务书》一起报审。7、任务反响存档综合秘书将部门审核完毕的《内部任务书》复印件作为任务承受反响提交需求部门留存，原件归档保存。8、任务登记启动任务治理处室依据部门意见对正式承受任务进展登记，并通知开发处室工程负责人。开发处室工程负责人接到通知后正式启动任务。如内部任务需交合作厂商完成，任务治理处室应将部门审核完毕的《外部任务书》交给开发处室。三、验收报告书流程说明1、任务验收测试验收测试由业务部门组织，依据业务部门制定的测试打算，依据任务需求和测试案例进展。信息技术部开发处室负责供给可用于验收测试的文档和程序升级包，并进呈现场问题处理；任务治理处室作为联系人，同时协调开发处室构建验收测试环境。2、验收结论签署验收测试通过后，业务部门对信息技术部提出的任务完成状况、实际工作量和费用进展确认，确认后，由信息技术部在《验收报告书》上填写“任务完成状况栏”并双方签字；由业务部门在《验收报告书》的“任务验收状况栏”和“任务验收结论栏”上出具验收意见、验收结论和下发意见，并双方签字。签字的《验收报告书》复印件交业务部门留存，原件交综合秘书归档保存书》电子版通过任务治理系统提交给相应的开发处室保存。四、外部任务书流程说明1、任务形成提交只针对一个内部任务分成假设干期实现的状况，其他状况见内部任务书流程。开发处室工程负责人依据任务内容填写《外部任务书》的“任务下达栏2、任务意见审批只针对一个内部任务分成假设干期实现的状况，其他状况见内部任务书流程。开发处室将经工程负责人、处室负责人签字的《外部任务书》报部门负责人审核并签字。3、任务下达启动部门审核完毕的《外部任务书合作厂商接到任务后，填写《外部任务书》的“任务接收栏4、软件文档审查任务开发测试完成后，合作厂商提交文档〔技术文档、测试文档和使用文档〕和程序升级包，开发处室进展审查。审查过的文档和程序升级包，由开发处室作为内部任务验收的根底提交给任务治理处室。5、验收结论签署费用进行确认，确认后，由合作厂商填写《外部任务书》的“任务完成状况栏”并双方签字；开发处室依据内部任务验收报告上业务部门的验收结论，在《外部任务书》的“任务验收状况栏”出具验收结论，并双方签字。签字的《外部任务书》原件一份交合作厂商，一份交综合秘书归档保存。期望帮到您！问题变更流程方组问题变更流程方组〕织求理验收报告书需管统用系应用门应部开头息信〔治理表》治理表》治理表》收测试方组〕织护发维开统件分析问题案、打算案、打算登记现试程序包测试环境程序下发系软用门应部息信〔任务治理表欢送下载，精选文档期望帮到您！期望帮到您！欢送下载，精选文档欢送下载，精选文档一、概要说明承受本流程作为具体问题处理方案进展处理。二、流程描述类似系统变更流程的系统缺陷修改子流程，也由任务提交和承受、任务实现、任务验收和程序下发上线四个阶段构成。1、任务提交和承受其中同时担当需求方和维护方，软件开发组织在其中担当维护方。以公司总部开发的业务系统为例，需求方是公司总部信息技术部应用治理处，维护方是公司总部信息技术部应用治理处和各软件开发处。流程如下：①、需求形成告方补充了解状况，将定位为系统缺陷的问题整理成《BUG②、需求方〔应用治理组织〕负责人审批BUG护方。③、需求评估软件开发组织对收到的《BUG治理表》进展分析，制定修改方案、打算。④、维护方〔软件开发组织〕负责人审批软件开发组织将修改方案、打算附在《BUG治理表》上，报请组织负责人签字批准后，回复应用治理组织。务。⑤、问题登记借助任务处理系统，应用治理组织对软件开发组织已列入打算的问题进展登记，软件开发组织每周对该登记表中的问题完成状态进展更。2、任务实现同系统变更流程的系统缺陷修改子流程。3、任务验收根本同同系统变更流程的系统缺陷修改子流程。不同之处在于：任务验收以应用治理组织为主，软件开发组织协作完成。测试案例和测试打算均由应用治理组织事先制定。应用治理组织还可选择由问题报告方进展验收测试，以问题报告方的反响作为测试结果。验收测试通过后，由应用维护组织出具验收结论和下发意见，并在验收报告上签字。4、程序下发同系统变更流程的系统缺陷修改子流程期望帮到您！紧急变紧急变更流程司门公部市户地用开头向问题受理专责人员提出紧急问题处理的需求补办文档和领导审批记录司术 员公技 人市息部责地信 了解问题状况进展上报补办文档和领导审批记录公术责省司技部负人指派紧急大事变/总息 关信 相人责司部负公术务省技任更处理负责人下发/上线请示批准了解问题状况进展推断紧急大事？否通知上报人员按照一般问题处理向部门负责人报告问题解决状况完毕向部门负责人请示下发/上线安排程序下发/上线信修急紧司部处公术改员省技修人息改是启动紧急大事变更处理流程进展优先级判定组织人员处理向部门负责人报告问题解决状况息急理使用专设账号进行处理记录紧急大事变更的处理过程补办文档和领导问题处理系统审批记录信紧欢送下载，精选文档期望帮到您！期望帮到您！欢送下载，精选文档欢送下载，精选文档紧急变更流程描述一、概要说明方案进展处理。紧急大事变更处理过程中的上报、请示、批准等可以通过或电子邮件的形式进展，待问题解决后再依据一般系统变更流程补办各类文档和领导审批记录。二、流程描述1、紧急大事的报告地市公司用户部门人员或其他人员觉察系统特别，导致业务处理无法正常进展，必需快速处理解决时，问题觉察人将问题报告给地市公司信息技术部专责人员。地市公司信息技术部专责人员依据问题信息，进展问题的初步诊断，如有可能，对问题缘由进展分析定位，并给出解决问题的建议，同时尽快向省公司信息技术部相关负责人〔部门经理或应用系统治理人员〕汇报。如为总公司开发系统的紧急问题，紧急问题将由省公司信息技术部最终上报到总公司信息技术部。2、紧急大事变更启动总/省公司信息技术部相关负责人接到紧急问题上报后，指定紧急大事变更任务负责人〔通常为应用系统治理人员，负责解决本次的紧急修改问题。紧急大事变更任务负责人准时与紧急问题上报公司的信息技术部人员进展争论和沟通，了解状况，并最终判定是否属于紧急大事。确定属于紧急大事后，由紧急修改任务负责人启动紧急大事变更流程，并依据其重要性和紧迫性安排优先权，组织人员实行相应的处理流程。否则，通知上报公司的信息技术部人员，请其依据一般问题变更流程处理，并将结果报告给总/省公司信息技术部相关负责人。3、紧急大事变更处理理同一般问题变更流程，包括分析、设计、实施、测试、验收，但需使用专设系统用户账号进展紧急大事变更，并由专人进展明确的紧急大事变更文档记录。4、紧急大事变更程序下发/上线/省公司信息技术部相关负责人报告，并提出下发/上线申请，经同意后，进展程序下发/上线。紧急大事变更流程的程序下发/上线同一般系统变更流程。5、补办文档和领导审批记录紧急问题得到妥当解决后，各级公司需要分别补办各类文档和领导审批记录，具体需要补办的内容包括以下：问题觉察人填写的紧急问题变更申请，其中包含问题觉察人对问题的描述。问题觉察人所在部门的负责人对申请的审批。总/省公司信息技术部相关负责人〔部门经理或相关岗位负责人〕对需求的审批和任务分派。开发人员书面的设计方案和总/省公司信息技术部相关负责人对设计方案的审批。用户部门/信息部门的测试记录和签字确认的测试结果。程序下发/上线专责人员填写的下发/上线申请和总/省公司信息技术部相关负责人的审批。6、文档整理归档统一归档治理。附件八 内部任务书中国人寿保险股份需求部门任务书编号

内部任务书

外部任务书编号 对应的外部任务书编号外部任务书下达后补录任务名称

系统名称系统名称英文缩写任务提交栏 *由业务部门填*

系统版本建议开头时间 建议完成时间任务紧急程度

一般 紧急 特急【*如包含多项内容，按挨次列***单工程负责人签字： 日期：部门负责人签字： 日期：A:开发

任务接收栏 *由信息技术部填*任务性质

B:改正性维护〔识别和订正软件错误、改正软件性能上的缺陷、排解实施中C:性维护〔因外部环境或数据环境的变化引发的修改〕D:完善性维护〔因用户对软件功能提出的功能和性能需求引发的修改〕E:其他〔上述以外的修正〕打算开头时间 打算完成时间处理优先级

排队 优先

任务实现方式

自行开发合作开发估量工作量 人天，合 人月本次任务打算税前开发费用

*注明小写金额和大写金*￥ 〔大写〕**估任务治理处室工程负责人签字： 日期：任务治理处室负责人签字： 日期：部门负责人签字： 日期：附件九 外部任务书甲方〔托付方〕 中国人寿保险股份乙方〔受托方〕外部任务书

任务书编号

格式：系统名称英文缩-RWSW-年月-序号

内部任务书编号 对应的内部任务书编号系统名称系统名称英文缩写 任务下达栏 *由甲方填*A:开发B:改正性维护〔识别和订正软件错误、改正软件性能上的缺陷、排解实施中的误使用〕C:适应性维护〔因外部环境或数据环境的变化引发的修改〕D:完善性维护〔因用户对软件功能提出的功能和性能需求引发的修改〕E:其他〔上述以外的修正〕打算开头时间 打算完成时间处理优先级

排队 优先 紧急估量工作量 人天，合 人月本次任务打算

*注明小写金额和大写金*税前开发费用 iv. ￥ 元〔大写〕〔含酬劳〕【*如包含多项内容，按挨次列***单开发处室工程负责人签字：开发处室工程负责人签字：日期：开发处室负责人签字：日期：部门负责人签字：日期：任务接收栏 *由乙方填*工程负责人签字： 日期：负责人签字： 日期：任务完成情况栏 *由乙方填写，双方签字确*实际开头时间 实际完成时间实际工作量

人天，合 人月本次任务实际*注明小写金额和大写金*税前开发费用￥ 元〔大写〕〔含酬劳〕*由乙方简要概述任务完成状况***等甲方开发处室工程负责人签字： 乙方工程负责人签字：日期：