软件项目开发规程_v22.docx

《软件项目开发规程_v22.docx》由会员分享，可在线阅读，更多相关《软件项目开发规程_v22.docx（35页珍藏版）》请在三一办公上搜索。

1、东亚银行（中国）研发中心SDLC项目开发规程V2.22014-6-20修订记录日期版本修订目的描述作者审核2010-1-21初稿文档初建张丹张丹2010-1-21V1.1审核修订贺耘贺耘2010-3-2V1.2根据第一次会议要求修订：FS评审阶段确定是否进入此规程；FS评审后由BA协调用户签字；用户在UAT与归并两项分开签字张丹贺耘2010-3-3V1.2强调“影响范围”贺耘贺耘2010-3-9V1.3强调FS评审之前开发人员就应尽早介入讨论；增加项目组提出的FS变更控制张丹贺耘2010-3-17V1.4更新单位名称，设计评审单修改“评审结论”张丹张丹2010-4-28V1.5将本文以及附件中

2、的“开发负责人”修订为“项目经理”，“深圳开发办”修订为“深圳PMO”；增加“第二轮SIT”过程；在设计评审中输入增加程序规格设计；FS评审、项目启动，设计评审、需求（FS）、计划变更控制过程中增加第二轮SIT测试负责人参与评审，对应过程做部分修改部分附录的签字模板应过程改动也做了相应的变化张丹贺耘2010-11-22V1.6FS评审时，将第二轮SIT负责人可参加修改为必须参加；FS评审单中增加“上线文档比照缺陷”选项张丹张丹2011-3-29V1.7对“第二轮SIT”执行过程作部分修改，并且出具SIT2测试报告书；在“投产评审”过程中增加用户与第二轮SIT负责人的参与，MIGRATION单增

3、加健康测试负责人签字；在“需求（FS）变更控制”过程中增加深圳PMO的参与；修改“附录5_第二轮SIT报告”为“附录5_SIT2测试报告书”修改“附录8_需求(FS)变更控制报告”中QA签字处增加PMO协商张丹厉琪、刘彬、贺耘2011-5-10增加对裁剪的大致描述张丹贺耘2011-5-27V1.8对“FS确认”增加投产演练、回退演练、压力测试的勾选； 对“项目启动”增加对架构设计的安排；并强调对投产演练、回退演练、压力测试、SIT2的安排；对“设计评审”增加架构设计的内容，加强设计评审的着重点：架构、业务流程设计、重难点技术设计；对“第二轮SIT”增加对SIT2配置与版本的描述；对“UAT与归

4、并”增加并行开发的内容，对归并的描述；增加对版本控制、环境与配置管理的描述对“投产评审”增加平台组（含MQ）与DBA参与；强调评审的着重点：投产步骤、差异分析、回退方案、影响范围对“需求（FS）变更控制”增加对变更评审的着重点：变更的内容、范围、影响、风险张丹贺耘、刘彬2011-10-31V1.8在版本投产单中增加对归并冲突的检查确认张丹贺耘2011-12-1V1.8概述中增加子行及监管要求：要求操作细则具有可操作、可检查、可追究责任的内容刘彬贺耘2012-7-11V1.9设计、归并、投产评审环节增加外围系统影响分析；投产评审增加归并冲突检查，专家领域，QA回退冲突检查；增加两项前提张丹贺耘、

5、刘彬、厉琪2012-8-3V2.0在FS阶段，新系统项目，增加架构设计（含架构验证）的审阅；删除设计评审中的架构设计，将详细架构设计包含至概要设计中；SIT2阶段，项目（大变更），增加SIT2申请单，并签署；UAT阶段，项目（大变更），增加UAT申请单，并签署；投产评审阶段，增加用户、运维手册的新增与更新，人员的培训；张丹黄传军、杨冬、贺耘、刘彬、唐麒、厉琪2013-7-19V2.1由于系统增多，在模板中增加NDS、EDP 、ECIF、YSF、YEB、YTF、CGMP、其他的选择，方便管理；增加FS模板、概要设计模板、优化SIT2模板；张丹张丽、李锦堂、贺耘2014-4-30V2.21、统一描

6、述：深圳研发中心 改为 东亚银行（中国）研发中心；深圳PMO 改为 东亚研发中心主管；项目（大变更） 改为 项目（重大变更）小变更 改为 一般变更；签署环节增加“信息总监”角色，用于项目、重大变更的加签；2、Migration单变更为软件产品投产申请单；3、完善了项目-变更-缺陷过程裁剪方案，各规模的项目中均增加了必须的版本描述单和软件产品投产申请单张丹、刘彬黄传军、杨冬、贺卫红、贺耘2014-6-18V2.2附录增加附录24：各阶段风险评估报告.xls，该表格应合规和风险要求，对于行内重大信息科技项目，需对各阶段风险进行评估和控制，该表格只做收录，不做会签；附录增加附录25_紧急投产窗口申请

7、单.docx，该表格用于对紧急窗口的申请刘彬贺耘目 录1 概述12 FS评审42.1 介绍42.2 FS评审规程42.2.1 目的42.2.2 角色与职责42.2.3 启动准则52.2.4 输入52.2.5 主要步骤52.2.6 输出62.2.7 结束准则63 项目启动73.1 介绍73.2 项目启动规程73.2.1 目的73.2.2 角色与职责73.2.3 启动准则83.2.4 输入83.2.5 主要步骤83.2.6 输出83.2.7 结束准则94 设计评审104.1 介绍104.2 设计评审规程104.2.1 目的104.2.2 角色与职责104.2.3 启动准则114.2.4 输入114

8、.2.5 主要步骤114.2.6 输出124.2.7 结束准则125 SIT135.1 介绍135.2 SIT规程135.2.1 目的135.2.2 角色与职责135.2.3 启动准则145.2.4 输入145.2.5 主要步骤145.2.6 输出145.2.7 结束准则146 第二轮SIT156.1 介绍156.2 第二轮SIT规程156.2.1 目的156.2.2 角色与职责156.2.3 启动准则166.2.4 输入166.2.5 主要步骤166.2.6 输出176.2.7 结束准则177 UAT与归并187.1 介绍187.2 UAT与归并规程187.2.1 目的187.2.2 角色与

9、职责187.2.3 启动准则197.2.4 输入197.2.5 主要步骤197.2.6输出207.2.7 结束准则208 投产评审218.1 介绍218.2 投产评审规程218.2.1 目的218.2.2 角色与职责218.2.3 启动准则228.2.4 输入228.2.5 主要步骤228.3.6 输出238.3.7 结束准则239 需求（FS）变更控制249.1 介绍249.2 需求（FS）变更控制规程249.2.1目的249.2.2 角色与职责249.2.3 启动准则259.2.4 输入259.2.5 主要步骤259.2.6 输出269.2.7 结束准则2610 项目计划变更控制2710.

10、1 介绍2710.2 项目计划变更控制规程2710.2.1 目的2710.2.2 角色与职责2710.2.3 启动准则2810.2.4 输入2810.2.5 主要步骤2810.2.6 输出2810.2.7 结束准则29项目开发规程1 概述本文依据下述关键点进行阐述： 里程碑设置l FS评审l 项目启动l 设计评审l SITl 第二轮SIT（可选）l UAT与归并l 投产评审 变更控制l 需求变更控制l 项目计划变更控制每个规程按照“目的”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”分别定义。前提：项目已完成可行性分析、立项的相关过程；项目开发过程中，涉及版本、

11、配置、网络、安全、平台（OS、中间件等）、DBA、运维等的配合，需遵循其有关制度标准。本文可根据项目规模、性质做出相应裁剪以适应实际项目开发情况，具体裁剪方式可见项目-变更-缺陷过程裁剪方案.xls。因操作不当导致案件发生的，将根据子行制订的“案件风险防范与案发事件的处理、整纠制度”追究相关人员责任。 2 FS评审2.1 介绍FS（Functional Specification）评审是指用户、项目组、BA三方共同依据需求说明书对FS进行评审，三方对FS达成共识后作出书面承诺，使FS文档具有合同效果。如果评审通过，那么FS可以正式发布，不可以被随便修改。项目的所有成员按照FS执行研发工作。若在

12、项目进行中遇到不可避免的问题导致需求说明书和FS更改，可参考“9 需求（FS）变更控制”规程，但项目已进入归并则不可再对FS作变更。若为新系统项目，FS评审中还涉及架构设计，其中包含架构验证；架构设计可在立项阶段完成；新系统项目有外购新系统与自主研发新系统两种类型。FS评审产生的主要文档有： FS评审报告，见模板。2.2 FS评审规程2.2.1 目的l 项目组、BA、用户三方依据需求说明书对FS进行评审，确保FS对需求的理解未出现偏差，并作书面承诺。l 按任务的规模、范围等确定裁剪方案，明确具体开发流程。l 若为新系统项目，则需对架构设计做出审阅。2.2.2 角色与职责 项目经理l 尽早参与F

13、S确定之前的需求讨论；l 填写FS评审报告，发起FS评审会议；l 参与FS评审会议，并做出书面承诺；l 若为新系统项目，提供架构设计，包含架构验证； 用户负责人l 提供需求说明书，参与FS评审会议，并做出书面承诺； BA负责人l 提供FS文档，参与FS评审会议，并做出书面承诺；l 协调获取用户对FS评审之签字，用户签字表示认可FS和项目组对需求理解正确； 东亚研发中心主管l 参与FS评审，根据相关人员意见确定项目开发的流程； QA负责人l 参与FS评审会议，并对FS评审过程执行的正确性做书面承诺；l 接收各方认可的需求说明书、FS、架构设计（新系统项目，则有）、FS评审报告存档； IT测试组负

14、责人l 须参与评审，无需做书面承诺；2.2.3 启动准则l 项目组应尽早安排人员参与用户和BA的FS讨论制定，且参与FS讨论的开发人员必须为今后此项目的开发成员；l 东亚研发中心主管已确定了项目经理；l 需求说明书和FS已经完成；l 若为新系统项目，还需架构设计，其中包含架构验证；2.2.4 输入l 需求说明书；l FS文档；l 若为新系统项目，还需架构设计，其中包含架构验证；2.2.5 主要步骤Step1 举行评审l 项目经理填写FS评审报告，并邀请东亚研发中心主管、BA、用户、QA、IT测试组负责人一起依据需求说明书对FS进行评审，确保FS与项目组的理解能够正确无误地反映需求说明书中用户的

15、意图。l 若为新系统项目，各方还需审阅架构设计，包含物理架构、应用架构描述和架构验证；架构验证侧重于系统软件（数据库、中间件、浏览器等）的验证；针对外购、自主研发的新系统项目，做典型交易测试（自主研发的项目可用较简单的现有系统典型交易来做），比照SLA指标进行评估；验证方法与结果表达可灵活表示。Step2 获取FS承诺l 若项目经理、用户、BA其中任何一方对FS理解存在分歧，则FS评审不通过；当三方达成共识，项目经理、用户、BA在FS评审报告中对FS文档作书面承诺签字，该FS具有合同效果。Step3 对项目的安排l QA与东亚研发中心主管会依据项目本身的性质以及综合各方意见确定任务的开发流程，

16、QA在FS评审报告中选择勾选：1项目 (重大变更)；2一般变更； 3小变更（上线文档比照缺陷）；4 项目是否需要第二轮SIT；5项目是否为新系统；6是否需要投产演练、回退演练、压力测试（针对项目与重大变更）。Step4 QA过程保证l 三方对FS做出书面承诺后，QA负责人与东亚研发中心主管协商确定，在FS评审报告中勾选项目安排，并签字确认FS评审过程执行正确，FS评审通过。2.2.6 输出l 项目经理、用户、BA、QA已签字的FS评审报告；l 通过评审各方认可的FS文档；l 若为新系统项目，通过各方审阅的架构设计；2.2.7 结束准则l QA接收签字完备的FS评审报告和已认可的FS文档、需求说

17、明书，架构设计（新系统项目，则有）存档。3 项目启动3.1 介绍项目启动是对项目计划的评审，项目经理和核心成员着手制定项目计划，并按计划执行研发和管理工作。通常项目计划由项目经理负责制定。一般计划需要明确开发人员，明确各开发阶段的任务与时间表，所需资源等；另外，计划中还需明确确定该项目是否需要概要设计；依据FS评审阶段对项目流程的裁剪，对涉及第二轮SIT、投产演练、回退演练、压力测试的安排也需做出相应计划。如果批准了项目计划，那么该计划书可以正式发布，不可以被随便修改。项目的所有成员按照项目计划执行研发与管理工作。若在项目进行中遇到不可避免的问题导致需要更改项目计划，可参考“10 项目计划变更

18、控制”项目立项阶段如果已经提供项目管理计划书，并明确产出了详细的实施日程计划，则可以以该实施计划为项目计划。项目启动产生的主要文档有： 项目计划评审报告，见模板。3.2 项目启动规程3.2.1 目的l 东亚研发中心主管、用户、环境配置组与第二轮SIT组（若项目计划中涉及到，也需参加；若不涉及则不需参加）评审项目计划，确保计划是合理的、符合现实的。3.2.2 角色与职责 项目经理l 提供项目计划，填写项目计划评审报告，发起项目计划评审；l 参与评审给出承诺； 东亚研发中心主管l 评审项目计划，并给出建议，给出书面承诺； 用户l 评审项目计划，并给出建议，给出书面承诺； 环境与配置组l 若项目涉及

19、到环境与配置，负责人需要参与评审项目计划，并给出建议，给出书面承诺；若不涉及则无需参加评审也无需签字承诺； 第二轮SIT负责人l 若项目涉及到第二轮SIT，则需要参与评审并签字承诺；若项目无需第二轮SIT则无需参与评审也无需做书面承诺； QAl 确定项目启动过程正确执行后接收项目计划、项目计划评审报告存档；3.2.3 启动准则l 项目组已经制定了项目计划；l 项目组已提交到此阶段完备的文档，至QA处，且前期开发流程正确执行；3.2.4 输入l 项目计划；3.2.5 主要步骤Step1 项目计划评审l 项目经理填写项目计划评审报告，并邀请东亚研发中心主管、用户、环境负责人、第二轮SIT负责人一起

20、评审项目计划。Step2 获取承诺l 东亚研发中心主管、用户、环境负责人、第二轮SIT负责人对项目计划各类安排的合理性等方面进行评审，各方认同后均在项目计划评审报告做书面承诺签字，评审通过，该项目计划正式生效。此后项目组不能随意修改项目计划，项目经理将项目计划和已签字的项目计划评审报告提交到QA处。Step3 QA过程保证l QA负责人确认项目启动过程正确执行，且之前的流程已完备，则接收项目计划评审报告与项目计划。3.2.6 输出l 东亚研发中心主管、项目经理、用户、环境与配置负责人与第二轮SIT负责人（不涉及无需签）均已签字的项目计划评审报告；l 通过评审各方认可的项目计划；3.2.7 结束

21、准则l QA接收已签字完备的项目计划评审报告和已认可的项目计划存档。 4 设计评审4.1 介绍设计文档一般由项目经理和项目骨干人员一起制定。若FS评审时确定项目需要第二轮SIT，则开发人员可与测试人员协商，是否制定程序规格设计。根据项目计划安排，项目经理组织相关人员评审设计，针对较大项目或重难点项目，评审应包含概要设计，项目组在其基础上进行详细设计；若项目确定有第二轮SIT，还可进行程序规格设计。项目经理组织人员评审详细设计（和/或程序规格设计，若需要）。评审通过，设计文档可以正式发布，不可以被随意修改。项目开发人员依据设计进行之后的编码工作。若无概要设计，则只需要评审详细设计（和/或程序规格

22、设计，若有）。注：概要设计可包含详细的架构设计之内容，标注明确即可。后文提及的DS（Design Specification）包括：概要设计、详细设计设计评审产生的主要文档有： 设计评审报告，见模板。4.2 设计评审规程4.2.1 目的l 东亚研发中心主管、项目组、BA、QA、第二轮SIT负责人一起评审详细设计（和/或概要设计、程序规格设计），确保设计是合理的、可实施的。4.2.2 角色与职责 项目经理l 提供详细设计（和/或概要设计），填写设计评审报告，并发起设计评审活动；l 若项目已计划安排了第二轮SIT，可提供程序规格设计（可选）；l 参与设计评审，给出书面承诺； 东亚研发中心主管l 评

23、审详细设计（和/或概要设计、程序规格设计），给出建议；l 评审通过后给出书面承诺； BAl 参与设计评审，给出建议； QAl 参与设计评审，确定设计评审过程正确执行后，签字并接收设计评审报告、详细设计（和/或概要设计、程序规格设计）存档； 第二轮SIT负责人l 若项目需要第二轮SIT，则参与设计评审，给出建议，给出书面承诺；若无需第二轮SIT，则无需参加评审也无需给出书面承诺；4.2.3 启动准则l 项目组已制定了详细设计（和/或概要设计）；l 若项目需要第二轮SIT，项目组可根据项目需要制定程序规格设计（可选）；l 项目组已提交到此阶段完备的文档，至QA处，且前期开发流程正确执行；4.2.4

24、 输入l 详细设计（和/或概要设计）；l 程序规格设计（项目需第二轮SIT，可提供）；4.2.5 主要步骤Step1 设计评审l 项目经理填写设计评审报告，邀请东亚研发中心主管、BA、QA、第二轮SIT负责人评审详细设计（和/或概要设计、程序规格设计）。Step2 获取评审承诺l 东亚研发中心主管、BA、QA、第二轮SIT负责人对详细设计（和/或概要设计、程序规格设计）进行评审；着重关注详细架构、业务流程设计、重难点技术、技术风险点、影响范围（本系统影响范围、外围系统影响范围）等关键点。l 各方认同后，东亚研发中心主管、项目经理、第二轮SIT负责人在设计评审报告中对设计文档作书面承诺签字，评审

25、通过。Step3 QA过程保证l 通过评审后，QA负责人在设计评审报告中签字确认此次设计评审过程执行正确，QA接收设计评审报告与详细设计（和/或概要设计、程序规格设计）存档。4.2.6 输出l 若对外围系统有所影响，项目经理初步与相关系统负责人协商；l 东亚研发中心主管、项目经理、QA、第二轮SIT负责人（不涉及无需签）已签字的设计评审报告；l 通过评审各方认可的详细设计（和/或概要设计、程序规格设计）；4.2.7 结束准则l QA接收签字完备的设计评审报告和已认可的详细设计（和/或概要设计、程序规格设计）存档。 5 SIT5.1 介绍SIT人员由项目经理组织，可以是本项目的开发人员，也可以是

26、非本项目开发人员，也可邀请用户一起参与。SIT人员应当根据项目的特征确定测试内容。一般地，SIT的主要内容包括： 功能测试：即测试软件业务功能是否正确，其依据是需求文档与FS。由于正确性是软件最重要的质量因素，所以功能测试必不可少。 性能测试：测试软件系统是否满足性能指标的要求，如响应时间，对并发压力的反应等。性能测试亦可安排在第二轮SIT或UAT阶段执行。SIT过程产生的主要文档有： SIT报告，见模板。5.2 SIT规程5.2.1 目的l 对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。5.2.2 角色与职责 项目经理l 项目经理组建SIT小组，并指定一名成员任

27、测试组长；l 审查SIT组制定的SIT用例；l 审查SIT组长提交的SIT报告，并做书面承诺； SIT组长l SIT组长与成员共同制定“测试用例”，并安排人员执行测试；l 将测试人员反馈的结果填写到SIT报告中，SIT完成后作出承诺，并将报告提交给项目经理审查； QAl 确定SIT过程正确执行后接收SIT报告；5.2.3 启动准则l FS和设计文档完成并得到各方认可之后，编码已完成；l 项目组已提交到此阶段完备的文档，至QA处，且前期开发流程正确执行；5.2.4 输入l FS、设计文档、代码5.2.5 主要步骤Step1 设计SIT用例l SIT组长提交“SIT用例”给开发人员和项目经理进行内

28、部评审。Step2 执行SITl SIT组长将测试结果记录在SIT报告中，并及时通报给开发人员与项目经理。Step3 SIT完成l SIT完成后，组长确认通过，并签字承诺SIT报告并提交给项目经理，项目经理评审后承诺签字，并将报告提交给QA处。Step4 QA过程保证l QA确认SIT过程正确执行，且之前的流程已完备，则接收SIT报告存档。5.2.6 输出l SIT组长、项目经理签字的SIT报告；l 通过SIT的代码；5.2.7 结束准则l QA接收签字完备的SIT报告存档。6 第二轮SIT6.1 介绍在项目FS评审时由东亚研发中心主管确定项目是否需要进行第二轮SIT(可简称：SIT2)，该过

29、程由前期裁剪确定是否执行，若确定执行则需要遵循以下规程，若无需，则此规程可以跳过。第二轮SIT由IT测试组负责执行，主要为功能测试与性能测试。第二轮SIT着重白盒测试。第二轮SIT过程产生的主要文档有： SIT2测试报告书，有功能测试与性能测试两类，见模板。6.2 第二轮SIT规程6.2.1 目的l 对最终软件系统进行更加全面的SIT测试，确保交付给用户的产品更加高质、高效。6.2.2 角色与职责 项目经理l 若为项目(重大变更)，填写提交SIT2申请单，申请进入SIT2阶段；l 酌情安排相关开发人员协助第二轮SIT；l 在SIT2配置库中发布基线，并提起版本申请（SIT2与UAT配置库应相同

30、）； 第二轮SIT负责人l 审核并签署SIT2申请单(项目(重大变更)，则有)；l 第二轮SIT负责人与成员按照其选定的测试方法进行测试分析，制定第二轮SIT测试方案，并安排人员执行测试；l 第二轮SIT负责人根据测试结果撰写SIT2测试报告书，并将报告提交给项目经理； QAl 审核并签署SIT2申请单，并接收签字完备的SIT2申请单(项目(重大变更)，则有)；l 依据版本清单制作SIT2版本，并在Change中发布；l 根据测试结果给出建议，确定第二轮SIT过程正确执行后接收SIT2测试报告书； 东亚研发中心主管l 根据测试结果给出建议；6.2.3 启动准则l 编码已完成、开发内部的SIT已

31、完成、通过评审的FS、DS、PS；l 项目组已提交到此阶段完备的文档，至QA处，且前期开发流程正确执行；6.2.4 输入l FS、DS、PS、代码、SIT报告；6.2.5 主要步骤Step1 第二轮SIT申请(若为项目（重大变更）,则需此步骤)l 若为项目(重大变更)，项目经理提交SIT2申请单到QA与第二轮SIT负责人处， QA确认项目过程执行正确且文档齐备，则签字承诺；SIT2负责人审核其SIT报告以及相关文档，通过后签字承诺。l 申请通过后，第二轮SIT组着手安排测试工作；项目经理提交签字完备的SIT2申请单到QA处存档。Step2 确定第二轮SIT测试点与测试范围l 第二轮SIT负责人

32、按照选定的测试方法进行测试分析，并参考开发人员的意见，确定第二轮SIT的测试点与范围。Step3 设计第二轮SIT方案与案例l 第二轮SIT组负责人与成员根据已确定的测试点与范围共同制定第二轮SIT方案，项目组可酌情参与。l 第二轮SIT组负责人与成员依据测试方案制定测试案例；l 若为项目(重大变更)，测试项需包含SLA（Service-Level Agreement，服务等级协议）典型交易测试（可与现存系统同类型交易测试比照）。Step4 SIT2版本生成l 项目经理在SIT2配置库中发布基线，并提起版本申请。l QA依据版本清单制作发布SIT2版本；版本部署完成（需遵循版本、配置等相关制度

33、）。Step5 执行第二轮SITl 测试人员依据测试方案以及案例进测试，并将结果汇总到第二轮SIT负责人处。Step6 第二轮SIT完成l 第二轮SIT完成后，第二轮SIT负责人将测试结果撰写成SIT2测试报告书提交给项目经理、QA、东亚研发中心主管，三方协商无异议后，项目经理将报告提交给QA处。Step7 QA过程保证l QA确认第二轮SIT过程正确执行，且之前的流程已完备，则接收SIT2测试报告书存档。6.2.6 输出l 项目经理、QA、第二轮SIT负责人已签字的SIT2申请单（项目(重大变更)，则有）；l 通过项目经理、QA、东亚研发中心主管审核的SIT2测试报告书；l 通过第二轮SIT

34、的版本；6.2.7 结束准则l QA接收通过审核的SIT2测试报告书存档。7 UAT与归并7.1 介绍UAT与归并测试是用户依据之前认可的需求说明书和FS对产品进行测试验收，确保产品符合之前的约定，并且形成最终可投产的版本。UAT版本通过全面的UAT后，Build Manager才能对代码进行归并，用户对归并版本再进行测试确保产品符合之前的约定。注意，归并后项目组将不接受用户的需求变更申请，用户可提起应用变更（Application Change Request），安排后续工作。UAT与归并产生的主要文档有： 用户测试报告，见模板。7.2 UAT与归并规程7.2.1 目的l Build Man

35、ager按投产计划对并行开发项目进行归并控制，检查程序冲突，发布基线。l 用户依据之前认可的需求说明书和FS进行测试，确保版本满足用户需求。 7.2.2 角色与职责 用户l 制定测试案例，将测试过程中出现的缺陷反馈给项目经理；l UAT与归并测试通过后，测试负责人在用户测试报告签字； 项目组l 若为项目(重大变更)，则项目经理填写提交UAT申请单，申请进入UAT阶段；l 在UAT配置库中发布基线；l 提交程序，申请归并；l 在Change中提起UAT版本、归并版本申请；l 项目经理和开发人员为用户工作提供协助，及时解决用户发现的问题；l 项目经理分析确认项目对外围系统的影响； Build Ma

36、nager（synergy角色）l 对项目经理提起的归并申请进行审核，安排归并顺序，检查程序冲突，在准生产配置库中发布基线；l 提醒、协助项目经理分析确认项目对外围系统的影响； QAl 审核并签署UAT申请单，并接收签字完备的UAT申请单(项目(重大变更)，则有)；l 依据版本清单制作UAT版本与归并版本，并在Change中发布；l 确定UAT与归并过程正确执行后接收用户测试报告； 环境与配置组l 从Change中获取版本，并部署； 第二轮SIT负责人l 若项目涉及到第二轮SIT，则需审核并签署UAT申请单；若未涉及到第二轮SIT，则可不参与(项目(重大变更)，则有)； 东亚研发中心主管l 审

37、核并签署UAT申请单(项目(重大变更)，则有)；注：SIT、SIT2、UAT串行7.2.3 启动准则l 编码、SIT都已经完成；l 完成“影响范围（本系统和外系统）”分析（通过代码扫描等），记录于设计文档，并提示用户和外系统；l 项目组对用户进行了必要的培训；l 正确的环境（由相应的环境与配置管理流程支持）；l 项目组已提交到此阶段完备的文档，至QA处，且前期开发流程正确执行；7.2.4 输入l 需求文档、FS；l 代码；7.2.5 主要步骤Step1 UAT申请 (若为项目(重大变更),则需此步骤)l 若为项目(重大变更)，则项目经理填写提交UAT申请单， 第二轮SIT负责人、项目经理、东亚

38、研发中心主管、QA根据项目进度、测试等情况作出审核。l 各方签字承诺后，UAT申请通过，项目经理将UAT申请单提交到QA处存档。Step2 UAT版本生成l UAT申请通过后，项目经理在UAT配置库中发布相关基线，并提起版本，由QA根据版本清单制作并发布版本，环境配置组部署完成（需遵循版本、配置等相关制度）。Step3 UAT测试l 用户制定“测试用例”，对版本进行全面的测试，确保产品符合之前约定的需求。Step4 UAT通过l 版本作全面的UAT并通过后，项目方可申请归并。Step5 归并l 用户UAT通过后，项目经理依据PMO每月发布的投产计划，提交代码申请准生产归并，Build Mana

39、ger审核，检查程序冲突，进行程序归并，并发布相关基线（需遵循归并相关制度）。l 若项目对外围系统有影响，项目经理及时向运维组反映，并协助运维负责人向相关系统提起变更申请(如能确定，可提前通知)。Step6 归并版本生成l 项目经理在Change中提起版本申请，QA根据版本清单制作发布归并版本（也可称为准生产版本），环境配置组部署完成（需遵循版本、配置等相关制度）。Step7 归并后测试l 用户对归并版本进行测试，确保产品符合需求。Step8 归并通过签字l 当版本通过了归并测试后，项目经理要求用户填写用户测试报告，用户测试负责人签字承诺，项目经理提交用户测试报告到QA处。Step9 QA过程

40、保证 l QA确认UAT与归并过程正确执行，且之前的流程已完备，则接收用户测试报告存档。7.2.6 输出l 第二轮SIT负责人、项目经理、东亚研发中心主管、QA已签字的UAT申请单（项目(重大变更)，则有）；l 用户已签字的用户测试报告；l 通过UAT的版本与通过归并测试的版本；7.2.7 结束准则l QA接收用户测试报告存档。8 投产评审8.1 介绍投产评审一般约定在投产窗口的前两天，涉及到各个相关的IT团队，大家共同评审。投产评审产生的主要文档有： 版本描述单，见附录10模板 软件产品投产申请单，见附录11模板。8.2 投产评审规程8.2.1 目的l 降低项目投产风险。8.2.2 角色与职

41、责 项目经理l 提供终版需求文档、FS文档、项目计划、DS文档、SIT报告、用户测试报告、项目上线计划、上线及回退步骤验证报告、Gap Analysis与上线、回退步骤（根据项目裁剪方案选择）、若有第二轮SIT，还需提供PS文档与SIT2测试报告书给QA组；l 对提供的文档进行讲解； 运维组、东亚研发中心主管、领域专家l 组织投产评审会议，邀请相关人员参加评审会议（会议由运维组发起）；l 参与投产评审，给出建议并做出书面承诺；l 领域专家对各自领域把关并书面承诺； QA l 参与投产评审，给出建议并做出书面承诺；l 提醒、协助项目经理分析确认项目对外围系统的影响； 环境与配置组l 参与投产评审

42、，并给出建议； 用户l 可酌情参与投产评审，并给出建议； 第二轮SIT负责人l 若项目涉及到第二轮SIT，可参与投产评审，并给出建议；若未涉及到第二轮SIT，则可不参与； 平台组（含MQ）、DBA等相关组l 若项目涉及其负责的内容，可参与投产评审，并给出建议；若未涉及，则可不参与；8.2.3 启动准则l 产品已通过用户的UAT测试与归并测试；l 项目经理撰写项目上线计划，并组织开发人员对版本做上线及回退步骤验证，填写上线及回退步骤验证报告、Gap Analysis与上线、回退步骤，提交到QA处；l 项目组已提交到此阶段完备的文档，至QA处，且前期开发流程正确执行；8.2.4 输入l 终版需求文

43、档、FS文档、项目计划、DS文档、SIT报告、用户测试报告、项目上线计划、上线及回退步骤验证报告、Gap Analysis与上线、回退步骤（根据项目裁剪方案选择）、若有第二轮SIT，还需提供PS文档与SIT2测试报告书；8.2.5 主要步骤Step1 举行投产评审会议l 运维经理发起投产评审会议，项目经理、QA、运维组、东亚研发中心主管、环境与配置组、用户、第二轮SIT负责人、平台组（含MQ）、DBA等相关人员参加，由项目经理依据所提交的材料内容以及实际开发过程对项目进行讲解，参加会议的各方在此基础上评审，着重投产步骤、差异分析、回退方案、影响范围（本系统影响范围、外围系统影响范围）等，各方给出评审意见。注：投产评审可为多项目、多变更、多缺陷同时举行。Step2 会议结束决议l 若任何一方不认同，则项目不能投产。l 评审通过后，项目经理要求用户、领域专家、QA、运维组在版本描述单中签字承诺；项目经理也签字承诺。Step3 会议通过后l 通过投产评审，确定项目可投产，则：l 从配置库角度，项目经理完成版本冲突检查。l 从投产版本角度，QA完成版本回退冲突自动检测。l 对投产版本的整包完成健康测试。l 环境与配置组负责人组织相关人员完成回退分析，会后撰写软件产品投产申请单，IT整包健康测试负责人、东亚研发中心主管签字承诺。l 若为新系统投