复旦光华之gh-变更控制程序v1..doc

变更控制程序 上海复旦光华信息科技股份有限公司7/71 目的通过变更管理，实现对配置项的变更控制，保证配置管理的整体实施效果。2 适用范围适用于项目开发过程中配置项的变更管理，如技术性文件（设计文档）及代码变更的管理。3 职责 项目实施部门负责变更的申请、实施、记录和验证。 项目负责人负责用户提出变更的接收和反馈。 项目负责人监控变更的配置项的当前状态，保证正在进行变更的配置项不允许发布。 内部提出的变更由项目负责人批准；用户提出的变更由项目负责人审核，相关部门负责人批准。 测试与质量管理部负责变更的监控，必要时组织评审和验证。4 工作程序4.1 引起变更要求的原因4.1.1 引起变更要求主要有如下原因： 用户提出的需求更改； 用户使用过程中发现的实现应用错误； 项目组测试过程中发现的错误或评审过程中发现的问题； 项目组或公司内部由于某种策略或技术变化的更改。4.2 变更要求的接收和处理4.2.1 用户提出需求变更的接收和解决4.2.1.1 对于用户提出的需求变更，填写变更请求控制表，同时可以保存来自用户的需求变更要求的书面文件（必须签字并盖章），作为记录存档，交商务运营部作为本项目合同的附件保存。4.2.1.2 收到来自用户的需求方面变更要求时，项目负责人组织相关人员（用户代表、本项目组的主要技术人员、本项目合同的责任人员，必要的时候可以包括第三方的专家。）对需求的变更要求进行评审，评审之前可对基本情况进行调研。评审的要求和过程和需求规格说明书的评审方式一致，评审结果填写变更请求控制表。项目负责人评审用户提出的需求变更时，若认为与合同（在质量、价格、交货日期、人员等开发计划方面）相比有较大变化时，应迅速上报，由部门负责人协调处理。上述过程相关内容由该过程的负责人填写入变更请求控制表。4.2.1.3 对于评审确认不可接受的需求更改，项目负责人应与用户协商解决方案。对于评审确认可接收的需求更改，需确定具体的修改内容、方法、计划和人员，填写变更请求控制表。4.2.1.4 接受的变更要求由项目负责人填写变更管理总账。4.2.2 用户发现问题的变更接收和解决4.2.2.1 当客户服务人员收到用户发现的本项目存在设计和实现问题时， 客户服务人员应将填写的顾客问题记录与处理，转交该项目的项目负责人，若该项目组已解散，则应由该相关部门的部门负责人组织有关人员进行处理。 接收问题的负责人将根据顾客问题记录与处理组织测试人员准备测试环境，重现用户发现的错误。验证结果应给出测试报告。如发现确有错误，项目负责人或部门负责人的指定人员填写变更请求控制表。 由项目负责人或部门负责人指定的被授权人根据问题的性质，按不合格品控制程序进行处理（如是软件问题，可以采取立即更改发布补丁版或下一版本解决的方式）。相关过程同时写入变更请求控制表。 接收问题的负责人应填写变更管理总账，记录提出的变更要求和变更解决方式。 对用户发现的问题，必要时将涉及质量问题的信息，及时通报测试与质量管理部，按改进控制程序的要求提出并实施纠正预防措施。4.2.2.2 当客户服务人员发现用户提出的问题是由于用户方使用系统不当造成时，由客户服务人员按服务控制程序进行解决。4.2.3 内部提出变更的接收和解决4.2.3.1 内部变更原因一：由于公司某种策略或技术的变化以及其它原因引起的项目设计文档或代码的更改，项目设计人员应填写变更请求控制表，直接提交项目负责人批准。4.2.3.2 内部变更原因二：在测试中发现的错误，（不含单元测试），测试人员应将测试报告提交项目负责人或项目负责人的授权人，由其组织错误定位，将错误下发给相应的开发人员解决, 填写变更请求表。4.2.3.3 内部变更原因三：在评审中发现的问题，评审人员应将问题提交项目负责人，由其组织相关人员解决问题, 填写变更请求表。4.2.3.4 文档的变更 变更承担人负责根据变更情况修改相关技术性文档，文档的变更必须在配置管理工具中检出后的版本基础上进行变更，变更后的版本应及时放到配置管理工具中。 文档的变更需要原审批负责人审批。 依照配置管理程序，项目负责人或项目负责人授权代理人对修改的技术性文档进行控制。4.2.3.5 代码的变更 不应直接修改程序行，应将旧的程序行注释掉，添加进修改后的新程序行； 在源程序的各个程序变更处，将变更人（记述负责承担变更任务的员工）和变更内容（简要记述变更原因和变更处）附加在注释语句中，作为变更的历史。 程序的变更必须在配置管理工具中检出后的版本基础上进行变更，变更后的版本应及时检到配置管理工具中。 依据配置管理程序，项目负责人或项目负责人授权代理人对修改的代码进行控制。4.2.3.6 项目负责人应填写变更管理总账，记录变更要求及解决情况。4.3 变更的关联项目中某一处的变更，往往会引发其它处随之而来的变更。项目负责人和相关的变更责任人应充分考虑所做变更对项目其它部分产生的影响，及时加以解决。解决办法与本程序上述变更的处理办法相同。项目在不同阶段存在不同的配置项，以下为各阶段控制的主要配置项：4.3.1 开发策划阶段 项目计划（含评审计划） 配置管理计划4.3.2 需求分析阶段 需求规格说明书或软件需求规格说明书4.3.3 设计阶段实现阶段 概要设计 详细设计 代码 集成测试计划 集成测试用例 集成测试报告 安装手册 用户手册4.3.4 测试阶段 系统测试计划 系统测试用例 系统测试报告4.3.5 交付阶段 验收交付申请书 验收测试计划 验收测试用例当某一阶段的配置项发生变更后，就有可能引发本阶段或后续阶段的配置项的变更。若进度发生调整，则应变更调整所对应的计划（可能包括：项目计划、配置管理计划、集成测试计划、系统测试计划、验收交付申请书、验收测试计划等）。4.4 变更结果的确认4.4.1 项目负责人或项目负责人的授权人确认各变更处理的结果, 填写变更请求控制表。若结果正确，则在变更管理总账中记录处置结果和确认人。4.4.2 文档变更后由该文档的原审批人审批；若原审批人不在岗，应向现审批人提供该文档的有关背景材料。4.4.3 当因用户提出需求变更或内部非错误因素引发变更，必须修改用户以前认可过的文档时，修改后的文档应得到用户的再认可。当有证据证明我方与用户意见一致、且对比当初的合同（在质量、价格、交货日期、人员等开发计划方面）没有问题时，只是错字、漏字、格式等的修改并与当初的合同没有冲突时，则不受此限制。4.4.4 代码修改后，应组织相应的再测试（集成测试、系统测试，甚至用户的验收测试）作为对变更的确认。4.5 变更结果的发布和通知4.5.1 对于用户提出的变更请求，由项目负责人或项目负责人授权人将处理结果通知维护人员，维护人员将处理结果记入顾客问题记录与处理（参见服务控制程序），并通知相关用户。4.5.2 技术性文档以及代码的变更由项目负责人或项目负责人授权人负责发布，并通知项目组和其他相关人员。5 相关