软件变更管理制度(试行)
软件变更管理制度(试行)资料
二、任务实现
信息部开发负责人（或由开发负责人会同合作厂商）根据《变更申请书》的需求描述，按照与软件开发流程同样的步骤，进行分析、设计、编码、测试，最终完成系统变更需求。
三、任务验收及用户测试
（一）任务验收以需求部门为主，信息部配合完成。
（八）
系统维护人员将评估结果附在《变更申请书》后，报请部门负责人签字批准后，正式向开发负责人下达任务。
如果任务实现由合作厂商完成，则由开发负责人按照与合作厂商签订的技术服务合同，填写《厂商维护申请单》（附件五），报请部门负责人签字批准后，正式向合作厂商下达任务。
（九）任务登记
（一十）
为了便于追踪各个系统变更需求的状态，维护人员需要对需求进行登记。
（六）
（七）如果任务实现由合作厂商完成，则由开发负责人员在内部任务验收完成后，根据需求部门的验收意见，在《厂商维护申请单》上出具验收结论并会同需求部门签署下发意见。
（八）
四、程序下发及系统上线
（一）下发程序经需求部门正式验收后由系统维护人员将要发布的程序进行打包下发。程序下发前，系统维护人员需填写《程序下发申请表》（附件七）并经过维护部门负责人审批。
第一十八条
第一十九条信息部按照事先明确的紧急变更定义做出判断，确定其优先级和影响程度，并进行相应的处理。
第二十条
第二十一条紧急变更过程中应使用专设系统用户帐号，由专责部门或人员启动紧急修改变更程序。信息部应对紧急变更的处理进行规范的文档记录。
第二十二条
第二十三条在紧急事件处理完成后，必须补办正式、完整的文档。详细流程参见《紧急变更流程》（附件二）。
第二十四条
软件系统变更管理制度(4篇)
软件系统变更管理制度机房信息系统变更制度第一条为规范应用系统变更与维护管理，提高应用软件管理水平，优化软件变更与维护管理流程，特制定本制度。
第二条系统变更工作分为四种类型。
功能完善维护、系统缺陷修改、统计报表生成、系统版本升级或流程、功能新增。
功能完善维护指根据业务部门的需求，对系统进行的功能完善性或适应性维护；系统缺陷修改指对一些系统功能或使用上的问题所进行的修复，这些问题是由于系统设计和实现上的缺陷而引发的；统计报表生成指为了满足业务部门统计报表数据生成的需要，而进行的不包含在应用系统功能之内的数据处理工作；系统版本升级或流程、功能新增是指对应用系统的版本进行更新，或因业务管理需要新增功能。
第三条系统变更工作以任务形式由需求方（一般为业务部门）和维护方（一般为信息部门、软件开发商）协作完成。
系统变更过程大致分为四个阶段：需求提交和接受、需求实现、需求验收和程序下发正式上线。
第四条需求部门提交系统变更需求，需求内容过多可整理成文档以附件形式一起上报，经部门负责人签字后提交给信息部门系统负责人。
第五条如属于功能完善维护、系统缺陷修改、统计报表生成的系统变更需求，系统负责人审核变更内容无误后，可直接将需求提交至开发人员进行处理；如要系统版本升级或流程、功能新增，需经信息1经理同意。
若变更牵涉到多业务部门的工作，并影响经营管理业务流程的执行，须经主管领导同意方可进行变更处理。
第六条软件开发人员对系统变更的需求实现过程，应遵循与软件开发过程相同的正式、统一的编码标准，并经过反复测试和正式验收后才能提交系统负责人。
第七条系统负责人要组织业务部门的系统最终用户对系统变更内容进行测试及验收，并撰写《用户测试、验收报告》，提交需求部门负责人或信息系统负责人签字确认后，方可将程序上线应用。
系统负责人每月要针对系统变更申请及完成情况进行汇总，记录在《软件需求及修改报告》中以备查。
第八条系统负责人要对系统最终用户，进行系统变更内容的培训和应用指导，并留存培训记录。
软件系统变更管理制度（4篇）
软件系统变更管理制度一、引言随着软件系统的不断更新和发展，为了保证软件系统的正常运行和性能优化，必然会需要进行系统的变更。
然而，软件系统变更的过程中涉及到许多风险，如对用户的影响、系统的稳定性等。
为了统一规范变更流程，降低风险，提高变更的效率和质量，建立软件系统变更管理制度是非常必要的。
二、变更管理目标1. 提供一个统一的变更流程，确保变更经过合理的评估和审批，以降低变更引起的风险；2. 确保变更的可跟踪性，方便查找和修复问题；3. 提高变更的效率和质量，减少用户感知到的变更对系统的影响；4. 确保变更的可控性，避免变更对生产环境的影响；5. 提供变更后的文档、培训和技术支持，确保变更的完整性和可持续性。
三、变更管理流程1. 变更请求变更请求来源于用户需求、任务分配或系统运行问题等。
变更请求需要提供变更的目的、需求、影响范围等详细信息，以便进行评估和审批。
2. 变更评估变更评估由评估小组负责，评估小组必须包含系统开发人员、测试人员和运维人员等相关角色。
评估内容包括变更的影响分析、风险评估、变更的工作量和时间估计等。
评估结果需要提供给变更审批者做参考。
3. 变更审批变更审批者根据评估结果和变更的紧急程度进行审批。
紧急程度的定义根据变更的影响范围和重要性来确定。
审批结果需要记录下来，作为变更执行的依据。
4. 变更规划和执行变更规划需要包括变更的详细步骤、执行人员的安排、变更的时间窗口等。
变更执行需要根据变更规划进行，如果发现问题需要立即停止变更，并进行回滚操作。
5. 变更验证和测试变更执行后需要进行验证和测试，以确保变更的正确性和稳定性。
验证和测试的方法和标准需要根据具体的变更类型和系统特点来确定。
6. 变更发布和文档更新变更验证和测试通过后，可以进行变更的发布。
发布包括变更代码的部署、数据库的升级等操作。
同时，相关的文档也需要进行更新，以反映变更后的系统状态。
7. 变更回顾和总结变更执行完成后，需要进行变更回顾和总结。
软件变更管理制度
软件变更管理制度一、总则为了规范软件变更的管理流程，提高软件变更的质量和效率，减少软件变更给系统带来的风险和影响，制定本制度。
二、适用范围本制度适用于公司内所有涉及软件开发、维护和管理的部门和人员，包括软件开发人员、测试人员、运维人员、管理人员等。
三、定义1. 软件变更：指软件系统中对现有源代码、配置、文档、数据等进行的修改或添加的操作。
2. 软件变更管理：指对软件变更进行计划、评审、实施、验证和记录的过程。
3. 变更请求：指由项目组织或系统用户提交的对现有软件系统进行修改或添加的请求。
4. 变更评审：指对变更请求进行审查和批准的过程。
5. 变更记录：指对软件变更过程中的相关信息进行记录和归档的文件。
四、变更管理流程1. 变更请求（1）变更请求应包括变更的目的、内容、影响分析、风险评估等相关信息。
（2）变更请求应由提交人员填写并提交给变更管理小组。
2. 变更评审（1）变更管理小组应对变更请求进行评审，并决定是否批准。
（2）评审应包括对变更请求的合理性、风险和影响的评估。
3. 变更计划（1）变更请求得到批准后，变更管理小组应制定变更计划，并确定变更的时间、范围和实施方法。
（2）变更计划应包括变更的目标、过程、角色分工、资源调配等相关信息。
4. 变更实施（1）根据变更计划，由变更责任人进行变更的实施。
（2）在实施过程中，应对变更进行跟踪和监控，并做好相关记录。
5. 变更验证（1）变更实施完成后，进行变更的验证和测试。
（2）验证和测试应包括对变更的功能、性能、稳定性等方面的检查和评估。
6. 变更记录（1）对变更的整个过程进行记录和归档。
（2）记录应包括变更的目的、内容、计划、实施、验证等相关信息。
五、责任和义务1. 软件开发人员应对软件变更的需求进行充分的调研和分析，并制定详细的变更方案。
2. 测试人员应对变更进行全面的测试和验证，确保变更后的软件系统能够符合预期的要求。
3. 运维人员应对软件变更的实施过程进行跟踪和监控，确保变更的安全性和稳定性。
软件系统变更管理制度（二篇）
软件系统变更管理制度是为了保证软件系统变更的规范性、安全性和高效性，确保变更的顺利实施和对系统维护的影响最小化，从而提高软件系统的可靠性和可维护性。
本文将详细介绍软件系统变更管理制度的内容。
一、变更管理的背景和目的软件系统是一个复杂的系统，随着软件系统的发展和用户需求的改变，对软件系统进行改进和修复是不可避免的。
然而，不合理的变更会给软件系统带来安全隐患、功能错误和性能问题等。
因此，建立一个有效的软件系统变更管理制度，是确保软件系统稳定运行和持续发展的必要条件。
软件系统变更管理的目的是通过规范和控制软件系统的变更过程，保证变更的质量和可控性，减少变更带来的风险和影响。
二、变更管理的基本原则1.需求分析和风险评估在变更管理的初期阶段，必须对变更的需求进行充分的分析和评估，确定变更的目标和可行性，同时对变更可能带来的风险进行评估和控制。
2.变更的分类和优先级将变更按照功能、性能、安全等方面进行分类，并确定不同变更的优先级，根据优先级进行变更的排期和实施。
3.变更的授权和审批严格按照变更管理制度的规定，对变更进行授权和审批，确保变更的合法性和必要性。
4.变更的跟踪和记录对每个变更进行严格的跟踪和记录，包括变更的发起人、变更的内容、变更的时间等信息，以便后续的追溯和管理。
5.变更的测试和验证对变更进行充分的测试和验证，确保变更的质量和可靠性，同时进行回归测试，避免变更引入新的错误。
6.变更的发布和回退在变更的发布前，必须进行充分的准备工作，确保变更的无缝衔接和影响的最小化。
同时，要预留回退方案，以应对变更引入的问题无法解决时的应急措施。
三、变更管理的主要流程1.变更申请：用户或系统维护人员根据需求和问题，发起变更申请并提交给变更管理团队。
2.变更评估和分析：变更管理团队对申请进行评估和分析，确定变更的目标和可行性，并进行风险评估。
3.变更授权和排期：根据评估结果，对变更进行授权和排期，确定变更的优先级。
软件系统变更管理制度
软件系统变更管理制度一、引言随着软件系统的不断更新和发展，为了保证软件系统的正常运行和性能优化，必然会需要进行系统的变更。
然而，软件系统变更的过程中涉及到许多风险，如对用户的影响、系统的稳定性等。
为了统一规范变更流程，降低风险，提高变更的效率和质量，建立软件系统变更管理制度是非常必要的。
二、变更管理目标1. 提供一个统一的变更流程，确保变更经过合理的评估和审批，以降低变更引起的风险；2. 确保变更的可跟踪性，方便查找和修复问题；3. 提高变更的效率和质量，减少用户感知到的变更对系统的影响；4. 确保变更的可控性，避免变更对生产环境的影响；5. 提供变更后的文档、培训和技术支持，确保变更的完整性和可持续性。
三、变更管理流程1. 变更请求变更请求来源于用户需求、任务分配或系统运行问题等。
变更请求需要提供变更的目的、需求、影响范围等详细信息，以便进行评估和审批。
2. 变更评估变更评估由评估小组负责，评估小组必须包含系统开发人员、测试人员和运维人员等相关角色。
评估内容包括变更的影响分析、风险评估、变更的工作量和时间估计等。
评估结果需要提供给变更审批者做参考。
3. 变更审批变更审批者根据评估结果和变更的紧急程度进行审批。
紧急程度的定义根据变更的影响范围和重要性来确定。
审批结果需要记录下来，作为变更执行的依据。
4. 变更规划和执行变更规划需要包括变更的详细步骤、执行人员的安排、变更的时间窗口等。
变更执行需要根据变更规划进行，如果发现问题需要立即停止变更，并进行回滚操作。
5. 变更验证和测试变更执行后需要进行验证和测试，以确保变更的正确性和稳定性。
验证和测试的方法和标准需要根据具体的变更类型和系统特点来确定。
6. 变更发布和文档更新变更验证和测试通过后，可以进行变更的发布。
发布包括变更代码的部署、数据库的升级等操作。
同时，相关的文档也需要进行更新，以反映变更后的系统状态。
7. 变更回顾和总结变更执行完成后，需要进行变更回顾和总结。
软件系统变更管理制度
软件系统变更管理制度软件系统变更管理制度1·引言1·1 目的本制度的目的是确保软件系统变更的有效管理，以确保系统的稳定性、可靠性和安全性。
1·2 范围本制度适用于公司内的所有软件系统变更，包括但不限于功能变更、修复漏洞、性能优化等。
1·3 定义●软件系统变更：指对现有软件系统进行的修改、更新或补充操作。
●变更请求：指需求方或系统管理员向变更管理团队提交的变更申请。
●变更管理团队：负责审批、安排和监控软件系统变更的团队。
●变更评估：对变更请求的分析和评估过程，确定变更的可行性和影响范围。
●变更实施：在变更评估通过后，对软件系统进行实际的修改、更新或补充操作。
●变更记录：对每个变更的详细记录，包括变更的原因、内容、影响等。
●变更后评估：对变更实施后系统性能、功能的评估。
2·变更管理流程2·1 提交变更请求需求方或系统管理员向变更管理团队提交变更请求，包括变更的原因、内容、期望实施时间等信息。
2·2 变更评估变更管理团队对变更请求进行评估，包括变更的可行性、影响范围、资源需求等，制定变更计划。
2·3 变更批准变更管理团队根据评估结果决定是否批准变更请求，并通知相关人员。
2·4 变更实施在变更批准后，变更管理团队组织相应人员进行变更操作，确保变更按计划实施。
2·5 变更回滚如果变更实施过程中出现问题或预期效果未达到，变更管理团队有权决定回滚变更操作。
2·6 变更记录变更管理团队对每个变更进行详细记录，包括变更的原因、内容、影响、实施时间等。
2·7 变更后评估变更管理团队对变更实施后的系统性能、功能进行评估，确保变更的有效性和稳定性。
3·变更管理团队职责3·1 变更请求评估负责对变更请求进行评估，确定变更的可行性和影响范围。
3·2 变更计划制定根据变更评估结果制定变更计划，包括资源需求、实施时间等。
软件系统变更管理制度范例（二篇）
软件系统变更管理制度范例1 引言软件系统变更管理是保证软件系统稳定运行和满足用户需求的重要环节，合理的变更管理制度可以有效地管理软件系统的变更流程，降低系统故障风险，提高变更效率。
本文将结合实际情况，提出一套完整的软件系统变更管理制度。
2 目的和范围2.1 目的本制度的目的是规范软件系统的变更管理流程，确保变更操作的合理性和有效性，提高变更管理效率。
2.2 范围本制度适用于公司内部所有软件系统的变更操作管理。
3 软件系统变更管理流程3.1 变更识别变更识别是指对系统中需要进行变更的需求或问题进行评估和确认，确定是否需要进行变更操作。
任何一个变更必须经过变更识别阶段的评估和确认后，方可继续进行下一步操作。
3.2 变更评估变更评估是指对变更的影响范围、风险和资源需求等进行评估，以确定是否可以进行变更操作。
评估结果需要记录并得到相关责任人的确认。
3.3 变更计划变更计划是根据变更评估结果，制定合理的变更操作计划，包括变更时间、流程和资源安排等。
变更计划需要事先与相关人员沟通并获得认可。
3.4 变更实施变更实施阶段是根据变更计划进行实际的变更操作，需要按照规定的流程和要求进行操作，并记录变更操作日志。
3.5 变更审核变更审核是指对变更操作进行评估和审核，确保变更操作的合理性和有效性。
变更审核需要由相关责任人进行，并记录审核结果。
3.6 变更验证变更验证是对变更操作的效果和结果进行验证，以确保变更是否达到预期的效果。
变更验证应由相关用户进行，并记录验证结果。
3.7 变更闭环变更闭环是指对变更操作的整个流程进行总结和归档，以反馈给相关人员进行经验总结和改进。
变更闭环阶段需要对变更操作日志、审核结果和验证结果进行整理和归档。
4 变更角色和责任4.1 变更发起者变更发起者是指发现系统中的问题或需求、并提出变更申请的人员。
变更发起者需要提供详细的变更申请信息，并配合变更评估和审核工作。
4.2 变更评估人员变更评估人员是对变更进行评估的专业人员，需要对变更的影响范围、风险和资源需求等进行全面的评估，并给出评估结果和建议。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件变更管理制度（试行）
第一节总则
第一条为规范软件变更与维护管理，提高软件管理水平，优化软件变更与维护管理流程，特制定本制度。
第二条软件变更与维护管理主要包括一般性变更、紧急变更、用户测试、版本控制、系统更新和权限管理等内容。
第三条本制度适用于中国铝业股份有限公司总部和各分子公司（含郑州研究院）（以下简称“公司”）。
第二节一般性变更流程
第四条需求部门提出系统变更需求，并将变更需求整理成《变更申请书》（附件三），由部门负责人审批后提交给信息部。
第五条信息部负责接受需求、分析需求，并提出系统变更建议。
信息部负责人审批《变更申请书》。
第六条信息部根据自行开发、合作开发和外包开发的不同要求组织实现系统变更需求，产生供发布的程序。
第七条信息部将所有的变更请求记录在《任务管理表》（附件四）中，并按照优先级安排实施的先后次序进行跟踪处理。
第八条信息部负责对系统变更过程的文档进行归档管理，所有文档至少保存三年。
详细流程参见《系统变更流程》（附件一）。
第三节紧急变更流程
第九条对于紧急变更，需求部门可以通过电子邮件或传真等书面形式提出申请。
第十条信息部按照事先明确的紧急变更定义做出判断，确定其优先级和
影响程度，并进行相应的处理。
第十一条紧急变更过程中应使用专设系统用户帐号，由专责部门或人员启动紧急修改变更程序。
信息部应对紧急变更的处理进行规范的文
档记录。
第十二条在紧急事件处理完成后，必须补办正式、完整的文档。
详细流程参见《紧急变更流程》（附件二）。
第四节系统的版本控制
第十三条软件变更时，加强版本控制，确保每次在最新的代码基础上进行更改。
第十四条应对下发的软件进行版本控制，由专责人员负责发布软件的版本管理。
第五节系统变更的责权分离
第十五条应加强对运行环境的访问控制，只允许授权的用户访问运行环境中的应用系统。
通过物理和逻辑隔离的手段，控制对运行环境的
访问。
第十六条限制开发人员对运行环境中应用程序文件夹的访问权限，只有经过授权的人员才拥有相应的权限。
第十七条对授权访问运行环境的人员进行详细记录，并定期进行检查。
第十八条普通用户只能通过前台登录系统，不能通过后台进行操作。
第十九条系统维护人员不应该拥有前台应用程序的访问权限，更不应该在前台应用程序中担任实际的操作任务。
第二十条禁止系统维护人员共享操作系统级别的账号。
第六节附则
第二十一条本制度由公司总部信息部负责解释和修订。
第二十二条本制度自发布之日起开始执行。
附件一系统变更流程
学习参考
系统变更流程步骤：
一、任务提交和接受：
本流程中需求部门为应用系统构建时提出需求的业务部门，维护部门为负责按照需求实际构建应用系统的信息部。
流程如下：
（一）需求形成：
需求方根据业务的需要，结合收到的其他用户部门要求，填写《变
更申请书》。
（二）需求方负责人审批
需求方将《变更申请书》报请部门负责人签字批准后，经指定途径
提交给信息部相关系统维护人员。
（三）需求评估
系统维护人员审查需求，会同相关开发负责人进行需求评估，产生
评估结果。
（四）信息部负责人审批
系统维护人员将评估结果附在《变更申请书》后，报请部门负责人
签字批准后，正式向开发负责人下达任务。
如果任务实现由合作厂商完成，则由开发负责人按照与合作厂商签
订的技术服务合同，填写《厂商维护申请单》（附件五），报请部门
负责人签字批准后，正式向合作厂商下达任务。
（五）任务登记
为了便于追踪各个系统变更需求的状态，维护人员需要对需求进行
登记。
信息部每周对《任务管理表》中的需求完成状态进行更新，以便信
息部负责人监控系统变更任务进度。
二、任务实现
信息部开发负责人（或由开发负责人会同合作厂商）根据《变更申请书》的需求描述，按照与软件开发流程同样的步骤，进行分析、设计、
编码、测试，最终完成系统变更需求。
三、任务验收及用户测试
（一）任务验收以需求部门为主，信息部配合完成。
（二）任务开发测试完成后，由开发负责人通知维护人员，并提供可用于验收测试的文档和程序升级包。
系统维护人员检查开发负责人提交
的资料是否完整、有效，版本是否最新，并对移交程序的内容进行
验收并形成记录。
（三）维护人员制定用户测试计划，由需求部门按照测试计划构建验收测试环境，进行验收测试并对测试内容进行记录。
验收测试通过后，
由需求部门在《验收报告书》（附件六）上出具验收结论并会同信
息部门签署下发意见。
（四）如果任务实现由合作厂商完成，则由开发负责人员在内部任务验收完成后，根据需求部门的验收意见，在《厂商维护申请单》上出具
验收结论并会同需求部门签署下发意见。
四、程序下发及系统上线
（一）下发程序经需求部门正式验收后由系统维护人员将要发布的程序进行打包下发。
程序下发前，系统维护人员需填写《程序下发申请
表》（附件七）并经过维护部门负责人审批。
（二）如果通过网络发布程序，则需通过指定路径或程序服务器发布，并且对相关访问人员的权限进行控制。
（三）下发程序接收公司的系统维护人员在收到下发的程序包后，联系需求部门进行安装测试，测试结束后在《系统上线申请表》（附件八）
的“需求部门意见”中填写验收意见，并签字确认。
（四）程序上线实施完毕以后，系统维护人员需填写《升级情况反馈表》（附件九），填写完毕后将《升级情况反馈表》上报到上级公司信
息部程序下发人员。
（五）各级公司系统维护人员应在软件程序变更上线前，严格遵照程序下发要求，建立完善的“回退”计划（参见《软件开发制度》中《试
运行计划》的应急预案）以避免升级失败，并确保系统及时更新到
最新版本。
五、文档整理归档
系统变更任务结束后，由专门人员将整个过程中产生文档的最终版本进行统一归档管理。
附件二紧急变更流程
学习参考
紧急变更流程步骤
紧急变更处理过程中的上报、请示、批准等需通过电子邮件、传真等书面形式进行，待问题解决后再按照一般系统变更流程补办各类文档
和审批记录。
一、紧急变更的报告
用户部门人员或其他人员发现系统异常，导致业务处理无法正常进行，必须迅速处理解决时，应及时将问题报告给信息部。
如公司信息部相关人员判定此问题需进行程序紧急变更，则报相关负责人要求执行程序紧急变更流程。
二、紧急变更的启动
信息部相关负责人接到紧急变更申报后，指定紧急变更任务负责人（通常为应用系统管理人员），负责解决本次的紧急变更问题。
紧急变
更任务负责人根据重要性和紧迫性区分变更的优先级，组织人员采取相
应的处理措施。
三、紧急变更的处理
紧急变更流程涉处理同一般程序变更流程处理步骤。
其中包括需求分析、程序设计、程序实施、程序测试、程序验收，但需使用专设的系
统用户账号进行紧急变更处理，并进行紧急变更的记录。
四、紧急变更程序的下发/上线
紧急变更任务负责人组织完成变更处理后，尽快向公司信息部相关负责人报告，并提出下发/上线申请，经批准后，进行程序下发/上线操
作。
五、补办文档和领导审批记录
紧急问题得到妥善解决后，需要分别补办各类文档和审批记录，其中包括：
（一）问题发现人填写的紧急问题变更申请，其中包含问题发现人对问题的描述。
（二）问题发现人所在部门的负责人对申请审批的记录。
（三）公司信息部相关负责人对需求的审批和任务分派记录。
（四）开发人员书面的设计方案和公司信息部相关负责人对设计方案的审批记录。
（五）需求部门/信息部的测试记录和签字确认的测试结果。
（六）程序下发/上线专责人员填写的下发/上线申请和公司信息部相关负责人的审批记录。
信息部负责人指派专人定期对紧急变更记录文档进行检查，
六、文档整理归档
按照一般问题系统变更流程的要求，各级公司将紧急事件变更整个过程中的各类文档进行统一归档管理
附件三变更申请书
附件四任务管理表
任务管理表
附件五厂商维护申请单
注：该表格一式两份，甲乙双方各执一份。
附件六验收报告书
注：该表格一式两份，需求部门、信息部双方各执一份。
附件七程序下发申请表
附件八系统上线申请表
. .. .. .
附件九升级情况反馈表
学习参考。