某研发中心SDLC项目开发规程概述.docx

某研发中心SDLC项目开发规程概述.docx

《某研发中心SDLC项目开发规程概述.docx》由会员分享，可在线阅读，更多相关《某研发中心SDLC项目开发规程概述.docx（38页珍藏版）》请在冰豆网上搜索。

某研发中心SDLC项目开发规程概述

东亚银行（中国）

研发中心SDLC项目开发规程

V2.2

2014-6-20

修订记录

日期

版本

修订目的描述

作者

审核

2010-1-21

初稿

文档初建

张丹

张丹

2010-1-21

V1.1

审核修订

贺耘

贺耘

2010-3-2

V1.2

根据第一次会议要求修订：

FS评审阶段确定是否进入此规程；FS评审后由BA协调用户签字；用户在UAT与归并两项分开签字

张丹

贺耘

2010-3-3

V1.2

强调“影响范围”

贺耘

贺耘

2010-3-9

V1.3

强调FS评审之前开发人员就应尽早介入讨论；增加项目组提出的FS变更控制

张丹

贺耘

2010-3-17

V1.4

更新单位名称，设计评审单修改“评审结论”

张丹

张丹

2010-4-28

V1.5

将本文以及附件中的“开发负责人”修订为“项目经理”，“深圳开发办”修订为“深圳PMO”；

增加“第二轮SIT”过程；

在设计评审中输入增加程序规格设计；

FS评审、项目启动，设计评审、需求（FS）、计划变更控制过程中增加第二轮SIT测试负责人参与评审，对应过程做部分修改

部分附录的签字模板应过程改动也做了相应的变化

张丹

贺耘

2010-11-22

V1.6

FS评审时，将第二轮SIT负责人可参加修改为必须参加；

FS评审单中增加“上线文档比照缺陷”选项

张丹

张丹

2011-3-29

V1.7

对“第二轮SIT”执行过程作部分修改，并且出具《SIT2测试报告书》；在“投产评审”过程中增加用户与第二轮SIT负责人的参与，MIGRATION单增加健康测试负责人签字；在“需求（FS）变更控制”过程中增加深圳PMO的参与；

修改“附录5_第二轮SIT报告”为“附录5_SIT2测试报告书”

修改“附录8_需求（FS）变更控制报告”中QA签字处增加PMO协商

张丹

厉琪、刘彬、贺耘

2011-5-10

增加对裁剪的大致描述

张丹

贺耘

2011-5-27

V1.8

对“FS确认”增加投产演练、回退演练、压力测试的勾选；

对“项目启动”增加对架构设计的安排；并强调对投产演练、回退演练、压力测试、SIT2的安排；

对“设计评审”增加架构设计的内容，加强设计评审的着重点：

架构、业务流程设计、重难点技术设计；

对“第二轮SIT”增加对SIT2配置与版本的描述；

对“UAT与归并”增加并行开发的内容，对归并的描述；增加对版本控制、环境与配置管理的描述

对“投产评审”增加平台组（含MQ）与DBA参与；强调评审的着重点：

投产步骤、差异分析、回退方案、影响范围

对“需求（FS）变更控制”增加对变更评审的着重点：

变更的内容、范围、影响、风险

张丹

贺耘、刘彬

2011-10-31

V1.8

在版本投产单中增加对归并冲突的检查确认

张丹

贺耘

2011-12-1

V1.8

概述中增加子行及监管要求：

要求操作细则具有可操作、可检查、可追究责任的内容

刘彬

贺耘

2012-7-11

V1.9

设计、归并、投产评审环节增加外围系统影响分析；投产评审增加归并冲突检查，专家领域，QA回退冲突检查；增加两项前提

张丹

贺耘、刘彬、厉琪

2012-8-3

V2.0

在FS阶段，新系统项目，增加架构设计（含架构验证）的审阅；

删除设计评审中的架构设计，将详细架构设计包含至概要设计中；

SIT2阶段，项目（大变更），增加SIT2申请单，并签署；

UAT阶段，项目（大变更），增加UAT申请单，并签署；

投产评审阶段，增加用户、运维手册的新增与更新，人员的培训；

张丹

黄传军、杨冬、

贺耘、

刘彬、

唐麒、

厉琪

2013-7-19

V2.1

由于系统增多，在模板中增加NDS、EDP、ECIF、YSF、YEB、YTF、CGMP、其他的选择，方便管理；增加FS模板、概要设计模板、优化SIT2模板；

张丹

张丽、李锦堂、贺耘

2014-4-30

V2.2

1、统一描述：

·深圳研发中心改为东亚银行（中国）研发中心；

·深圳PMO改为东亚研发中心主管；

·项目（大变更）改为项目（重大变更）

小变更改为一般变更；

·签署环节增加“信息总监”角色，用于项目、重大变更的加签；

2、Migration单变更为《软件产品投产申请单》；

3、完善了《项目-变更-缺陷过程裁剪方案》，各规模的项目中均增加了必须的《版本描述单》和《软件产品投产申请单》

张丹、刘彬

黄传军、杨冬、贺卫红、

贺耘

2014-6-18

V2.2

附录增加《附录24：

各阶段风险评估报告.xls》，该表格应合规和风险要求，对于行内重大信息科技项目，需对各阶段风险进行评估和控制，该表格只做收录，不做会签；

附录增加《附录25_紧急投产窗口申请单.docx》，该表格用于对紧急窗口的申请

刘彬

贺耘

1概述

本文依据下述关键点进行阐述：

✧里程碑设置

●FS评审

●项目启动

●设计评审

●SIT

●第二轮SIT（可选）

●UAT与归并

●投产评审

✧变更控制

●需求变更控制

●项目计划变更控制

每个规程按照“目的”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”分别定义。

前提：

项目已完成可行性分析、立项的相关过程；项目开发过程中，涉及版本、配置、网络、安全、平台（OS、中间件等）、DBA、运维等的配合，需遵循其有关制度标准。

本文可根据项目规模、性质做出相应裁剪以适应实际项目开发情况，具体裁剪方式可见《项目-变更-缺陷过程裁剪方案.xls》。

因操作不当导致案件发生的，将根据子行制订的“案件风险防范与案发事件的处理、整纠制度”追究相关人员责任。

2FS评审

2.1介绍

FS（FunctionalSpecification）评审是指用户、项目组、BA三方共同依据《需求说明书》对FS进行评审，三方对FS达成共识后作出书面承诺，使FS文档具有合同效果。

如果评审通过，那么FS可以正式发布，不可以被随便修改。

项目的所有成员按照FS执行研发工作。

若在项目进行中遇到不可避免的问题导致《需求说明书》和FS更改，可参考“9需求（FS）变更控制”规程，但项目已进入归并则不可再对FS作变更。

若为新系统项目，FS评审中还涉及《架构设计》，其中包含架构验证；《架构设计》可在立项阶段完成；新系统项目有外购新系统与自主研发新系统两种类型。

FS评审产生的主要文档有：

✧《FS评审报告》，见模板。

2.2FS评审规程

2.2.1目的

●项目组、BA、用户三方依据《需求说明书》对FS进行评审，确保FS对需求的理解未出现偏差，并作书面承诺。

●按任务的规模、范围等确定裁剪方案，明确具体开发流程。

●若为新系统项目，则需对《架构设计》做出审阅。

2.2.2角色与职责

✧项目经理

●尽早参与FS确定之前的需求讨论；

●填写《FS评审报告》，发起FS评审会议；

●参与FS评审会议，并做出书面承诺；

●若为新系统项目，提供《架构设计》，包含架构验证；

✧用户负责人

●提供《需求说明书》，参与FS评审会议，并做出书面承诺；

✧BA负责人

●提供FS文档，参与FS评审会议，并做出书面承诺；

●协调获取用户对FS评审之签字，用户签字表示认可FS和项目组对需求理解正确；

✧东亚研发中心主管

●参与FS评审，根据相关人员意见确定项目开发的流程；

✧QA负责人

●参与FS评审会议，并对FS评审过程执行的正确性做书面承诺；

●接收各方认可的《需求说明书》、FS、《架构设计》（新系统项目，则有）、《FS评审报告》存档；

✧IT测试组负责人

●须参与评审，无需做书面承诺；

2.2.3启动准则

●项目组应尽早安排人员参与用户和BA的FS讨论制定，且参与FS讨论的开发人员必须为今后此项目的开发成员；

●东亚研发中心主管已确定了项目经理；

●《需求说明书》和FS已经完成；

●若为新系统项目，还需《架构设计》，其中包含架构验证；

2.2.4输入

●《需求说明书》；

●FS文档；

●若为新系统项目，还需《架构设计》，其中包含架构验证；

2.2.5主要步骤

[Step1]举行评审

●项目经理填写《FS评审报告》，并邀请东亚研发中心主管、BA、用户、QA、IT测试组负责人一起依据《需求说明书》对FS进行评审，确保FS与项目组的理解能够正确无误地反映《需求说明书》中用户的意图。

●若为新系统项目，各方还需审阅《架构设计》，包含物理架构、应用架构描述和架构验证；架构验证侧重于系统软件（数据库、中间件、浏览器等）的验证；针对外购、自主研发的新系统项目，做典型交易测试（自主研发的项目可用较简单的现有系统典型交易来做），比照SLA指标进行评估；验证方法与结果表达可灵活表示。

[Step2]获取FS承诺

●若项目经理、用户、BA其中任何一方对FS理解存在分歧，则FS评审不通过；当三方达成共识，项目经理、用户、BA在《FS评审报告》中对FS文档作书面承诺签字，该FS具有合同效果。

[Step3]对项目的安排

●QA与东亚研发中心主管会依据项目本身的性质以及综合各方意见确定任务的开发流程，QA在《FS评审报告》中选择勾选：

1项目（重大变更）；2一般变更；3小变更（上线文档比照缺陷）；4项目是否需要第二轮SIT；5项目是否为新系统；6是否需要投产演练、回退演练、压力测试（针对项目与重大变更）。

[Step4]QA过程保证

●三方对FS做出书面承诺后，QA负责人与东亚研发中心主管协商确定，在《FS评审报告》中勾选项目安排，并签字确认FS评审过程执行正确，FS评审通过。

2.2.6输出

●项目经理、用户、BA、QA已签字的《FS评审报告》；

●通过评审各方认可的FS文档；

●若为新系统项目，通过各方审阅的《架构设计》；

2.2.7结束准则

●QA接收签字完备的《FS评审报告》和已认可的FS文档、《需求说明书》，《架构设计》（新系统项目，则有）存档。

3项目启动

3.1介绍

项目启动是对《项目计划》的评审，项目经理和核心成员着手制定《项目计划》，并按计划执行研发和管理工作。

通常《项目计划》由项目经理负责制定。

一般计划需要明确开发人员，明确各开发阶段的任务与时间表，所需资源等；另外，计划中还需明确确定该项目是否需要概要设计；依据FS评审阶段对项目流程的裁剪，对涉及第二轮SIT、投产演练、回退演练、压力测试的安排也需做出相应计划。

如果批准了《项目计划》，那么该计划书可以正式发布，不可以被随便修改。

项目的所有成员按照《项目计划》执行研发与管理工作。

若在项目进行中遇到不可避免的问题导致需要更改《项目计划》，可参考“10项目计划变更控制”

项目立项阶段如果已经提供《项目管理计划书》，并明确产出了详细的实施日程计划，则可以以该实施计划为项目计划。

项目启动产生的主要文档有：

✧《项目计划评审报告》，见模板。

3.2项目启动规程

3.2.1目的

●东亚研发中心主管、用户、环境配置组与第二轮SIT组（若项目计划中涉及到，也需参加；若不涉及则不需参加）评审《项目计划》，确保计划是合理的、符合现实的。

3.2.2角色与职责

✧项目经理

●提供《项目计划》，填写《项目计划评审报告》，发起项目计划评审；

●参与评审给出承诺；

✧东亚研发中心主管

●评审《项目计划》，并给出建议，给出书面承诺；

✧用户

●评审《项目计划》，并给出建议，给出书面承诺；

✧环境与配置组

●若项目涉及到环境与配置，负责人需要参与评审《项目计划》，并给出建议，给出书面承诺；若不涉及则无需参加评审也无需签字承诺；

✧第二轮SIT负责人

●若项目涉及到第二轮SIT，则需要参与评审并签字承诺；若项目无需第二轮SIT则无需参与评审也无需做书面承诺；

✧QA

●确定项目启动过程正确执行后接收《项目计划》、《项目计划评审报告》存档；

3.2.3启动准则

●项目组已经制定了《项目计划》；

●项目组已提交到此阶段完备的文档，至QA处，且前期开发流程正确执行；

3.2.4输入

●《项目计划》；

3.2.5主要步骤

[Step1]项目计划评审

●项目经理填写《项目计划评审报告》，并邀请东亚研发中心主管、用户、环境负责人、第二轮SIT负责人一起评审《项目计划》。

[Step2]获取承诺

●东亚研发中心主管、用户、环境负责人、第二轮SIT负责人对《项目计划》各类安排的合理性等方面进行评审，各方认同后均在《项目计划评审报告》做书面承诺签字，评审通过，该《项目计划》正式生效。

此后项目组不能随意修改《项目计划》，项目经理将《项目计划》和已签字的《项目计划评审报告》提交到QA处。

[Step3]QA过程保证

●QA负责人确认项目启动过程正确执行，且之前的流程已完备，则接收《项目计划评审报告》与《项目计划》。

3.2.6输出

●东亚研发中心主管、项目经理、用户、环境与配置负责人与第二轮SIT负责人（不涉及无需签）均已签字的《项目计划评审报告》；

●通过评审各方认可的《项目计划》；

3.2.7结束准则

●QA接收已签字完备的《项目计划评审报告》和已认可的《项目计划》存档。

4设计评审

4.1介绍

设计文档一般由项目经理和项目骨干人员一起制定。

若FS评审时确定项目需要第二轮SIT，则开发人员可与测试人员协商，是否制定《程序规格设计》。

根据《项目计划》安排，项目经理组织相关人员评审设计，针对较大项目或重难点项目，评审应包含《概要设计》，项目组在其基础上进行详细设计；若项目确定有第二轮SIT，还可进行程序规格设计。

项目经理组织人员评审《详细设计》（和/或《程序规格设计》，若需要）。

评审通过，设计文档可以正式发布，不可以被随意修改。

项目开发人员依据设计进行之后的编码工作。

若无概要设计，则只需要评审《详细设计》（和/或《程序规格设计》，若有）。

注：

《概要设计》可包含详细的架构设计之内容，标注明确即可。

后文提及的DS（DesignSpecification）包括：

《概要设计》、《详细设计》

设计评审产生的主要文档有：

✧《设计评审报告》，见模板。

4.2设计评审规程

4.2.1目的

●东亚研发中心主管、项目组、BA、QA、第二轮SIT负责人一起评审《详细设计》（和/或《概要设计》、《程序规格设计》），确保设计是合理的、可实施的。

4.2.2角色与职责

✧项目经理

●提供《详细设计》（和/或《概要设计》），填写《设计评审报告》，并发起设计评审活动；

●若项目已计划安排了第二轮SIT，可提供《程序规格设计》（可选）；

●参与设计评审，给出书面承诺；

✧东亚研发中心主管

●评审《详细设计》（和/或《概要设计》、《程序规格设计》），给出建议；

●评审通过后给出书面承诺；

✧BA

●参与设计评审，给出建议；

✧QA

●参与设计评审，确定设计评审过程正确执行后，签字并接收《设计评审报告》、《详细设计》（和/或《概要设计》、《程序规格设计》）存档；

✧第二轮SIT负责人

●若项目需要第二轮SIT，则参与设计评审，给出建议，给出书面承诺；若无需第二轮SIT，则无需参加评审也无需给出书面承诺；

4.2.3启动准则

●项目组已制定了《详细设计》（和/或《概要设计》）；

●若项目需要第二轮SIT，项目组可根据项目需要制定《程序规格设计》（可选）；

●项目组已提交到此阶段完备的文档，至QA处，且前期开发流程正确执行；

4.2.4输入

●《详细设计》（和/或《概要设计》）；

●《程序规格设计》（项目需第二轮SIT，可提供）；

4.2.5主要步骤

[Step1]设计评审

●项目经理填写《设计评审报告》，邀请东亚研发中心主管、BA、QA、第二轮SIT负责人评审《详细设计》（和/或《概要设计》、《程序规格设计》）。

[Step2]获取评审承诺

●东亚研发中心主管、BA、QA、第二轮SIT负责人对《详细设计》（和/或《概要设计》、《程序规格设计》）进行评审；着重关注详细架构、业务流程设计、重难点技术、技术风险点、影响范围（本系统影响范围、外围系统影响范围）等关键点。

●各方认同后，东亚研发中心主管、项目经理、第二轮SIT负责人在《设计评审报告》中对设计文档作书面承诺签字，评审通过。

[Step3]QA过程保证

●通过评审后，QA负责人在《设计评审报告》中签字确认此次设计评审过程执行正确，QA接收《设计评审报告》与《详细设计》（和/或《概要设计》、《程序规格设计》）存档。

4.2.6输出

●若对外围系统有所影响，项目经理初步与相关系统负责人协商；

●东亚研发中心主管、项目经理、QA、第二轮SIT负责人（不涉及无需签）已签字的《设计评审报告》；

●通过评审各方认可的《详细设计》（和/或《概要设计》、《程序规格设计》）；

4.2.7结束准则

●QA接收签字完备的《设计评审报告》和已认可的《详细设计》（和/或《概要设计》、《程序规格设计》）存档。

5SIT

5.1介绍

SIT人员由项目经理组织，可以是本项目的开发人员，也可以是非本项目开发人员，也可邀请用户一起参与。

SIT人员应当根据项目的特征确定测试内容。

一般地，SIT的主要内容包括：

✧功能测试：

即测试软件业务功能是否正确，其依据是需求文档与FS。

由于正确性是软件最重要的质量因素，所以功能测试必不可少。

✧性能测试：

测试软件系统是否满足性能指标的要求，如响应时间，对并发压力的反应等。

性能测试亦可安排在第二轮SIT或UAT阶段执行。

SIT过程产生的主要文档有：

✧《SIT报告》，见模板。

5.2SIT规程

5.2.1目的

●对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。

5.2.2角色与职责

✧项目经理

●项目经理组建SIT小组，并指定一名成员任测试组长；

●审查SIT组制定的SIT用例；

●审查SIT组长提交的《SIT报告》，并做书面承诺；

✧SIT组长

●SIT组长与成员共同制定“测试用例”，并安排人员执行测试；

●将测试人员反馈的结果填写到《SIT报告》中，SIT完成后作出承诺，并将报告提交给项目经理审查；

✧QA

●确定SIT过程正确执行后接收《SIT报告》；

5.2.3启动准则

●FS和设计文档完成并得到各方认可之后，编码已完成；

●项目组已提交到此阶段完备的文档，至QA处，且前期开发流程正确执行；

5.2.4输入

●FS、设计文档、代码

5.2.5主要步骤

[Step1]设计SIT用例

●SIT组长提交“SIT用例”给开发人员和项目经理进行内部评审。

[Step2]执行SIT

●SIT组长将测试结果记录在《SIT报告》中，并及时通报给开发人员与项目经理。

[Step3]SIT完成

●SIT完成后，组长确认通过，并签字承诺《SIT报告》并提交给项目经理，项目经理评审后承诺签字，并将报告提交给QA处。

[Step4]QA过程保证

●QA确认SIT过程正确执行，且之前的流程已完备，则接收《SIT报告》存档。

5.2.6输出

●SIT组长、项目经理签字的《SIT报告》；

●通过SIT的代码；

5.2.7结束准则

●QA接收签字完备的《SIT报告》存档。

6第二轮SIT

6.1介绍

在项目FS评审时由东亚研发中心主管确定项目是否需要进行第二轮SIT（可简称：

SIT2），该过程由前期裁剪确定是否执行，若确定执行则需要遵循以下规程，若无需，则此规程可以跳过。

第二轮SIT由IT测试组负责执行，主要为功能测试与性能测试。

第二轮SIT着重白盒测试。

第二轮SIT过程产生的主要文档有：

✧《SIT2测试报告书》，有功能测试与性能测试两类，见模板。

6.2第二轮SIT规程

6.2.1目的

●对最终软件系统进行更加全面的SIT测试，确保交付给用户的产品更加高质、高效。

6.2.2角色与职责

✧项目经理

●若为项目（重大变更），填写提交《SIT2申请单》，申请进入SIT2阶段；

●酌情安排相关开发人员协助第二轮SIT；

●在SIT2配置库中发布基线，并提起版本申请（SIT2与UAT配置库应相同）；

✧第二轮SIT负责人

●审核并签署《SIT2申请单》（项目（重大变更），则有）；

●第二轮SIT负责人与成员按照其选定的测试方法进行测试分析，制定第二轮SIT测试方案，并安排人员执行测试；

●第二轮SIT负责人根据测试结果撰写《SIT2测试报告书》，并将报告提交给项目经理；

✧QA

●审核并签署《SIT2申请单》，并接收签字完备的《SIT2申请单》（项目（重大变更），则有）；

●依据版本清单制作SIT2版本，并在Change中发布；

●根据测试结果给出建议，确定第二轮SIT过程正确执行后接收《SIT2测试报告书》；

✧东亚研发中心主管

●根据测试结果给出建议；

6.2.3启动准则

●编码已完成、开发内部的SIT已完成、通过评审的FS、DS、PS；

●项目组已提交到此阶段完备的文档，至QA处，且前期开发流程正确执行；

6.2.4输入

●FS、DS、PS、代码、《SIT报告》；

6.2.5主要步骤

[Step1]第二轮SIT申请（若为项目（重大变更）,则需此步骤）

●若为项目（重大变更），项目经理提交《SIT2申请单》到QA与第二轮SIT负责人处，QA确认项目过程执行正确且文档齐备，则签字承诺；SIT2负责人审核其《SIT报告》以及相关文档，通过后签字承诺。

●申请通过后，第二轮SIT组着手安排测试工作；项目经理提交签字完备的《SIT2申请单》到QA处存档。

[Step2]确定第二轮SIT测试点与测试范围

●第二轮SIT负责人按照选定的测试方法进行测试分析，并参考开发人员的意见，确定第二轮SIT的测试点与范围。

[Step3]设计第二轮SIT方案与案例

●第二轮SIT组负责人与成员根据已确定的测试点与范围共同制定第二轮SIT方案，项目组可酌情参与。

●第二轮SIT组负责人与成员依据测试方案制定测试案例；

●若为项目（重大变更），测试项需包含SLA（Service-LevelAgreement，服务等级协议）典型交易测试（可与现存系统同类型交易测试比照）。

[Step4]SIT2版本生成

●项目经理在SIT2配置库中发布基线，并提起版本申请。

●QA依据版本清单制作发布SIT2版本；版本部署完成（需遵循版本、配置等相关制度）。

[Step5]执行第二轮SIT

●测试人员依据测试方案以及案例进测试，并将结果汇总到第二轮SIT负责人处。

[Step6]第二轮SIT完成

●第二轮SIT完成后，第二轮SIT负责人将测试结果撰写成《SIT2测试报告书》提交给项目经理、QA、东亚研发中心主管，三方协商无异议后，项目经理将报告提交给QA处。

[Step7]QA过程保证

●QA确认第二轮SIT过程正确执行，且之前的流程已完备，则接收《SIT2测试报告书》存档