IT项目实施与管理方案投标书.docx

1.1 项目实行与管理
1.1.1 项目实行措施论
针对南京银行企业服务总线系统项目，高伟达企业基于对客户需求、业务目、业务能力和IT环境理解，结合数年软件开发和系统实行经验，将项目实行周期划分为六个活动阶段，保证在项目生命周期内，应用合理项目管理和控制技术。通过专注于使客户投资回报最大化，和使客户投资风险最小化关键战略和战术领域，加紧项目实行速度，使得项目成功地完毕。这些阶段特性是可循环往复性，使客户可以尽快地获得新应用系统所带来好处。
1.1.1.1 项目定义阶段
在这个阶段, 所有与分期实行有关项目活动都被明确定义, 项目"项目利益有关者"被指定，项目经理和客户项目经理角色和职责被传达给所有"项目利益有关者"。管理项目所需项目控制构造被定义,所有需要项目规划文献被创立, 客户业务问题和被用来衡量项目成功衡量原则被确认。
制定处理方案范围，在一种高级别上定义哪些模块将被实行，估算预期需要客户化程度, 以及勾画出在产品之外需要开发内容和要提交技术成果。处理方案范围文档包括处理方案范围概述, 功能范围, 流程范围, 客户化问题, 其他风险, 外部依赖条件以及假设。这个工作为未来项目决策, 统一或到达"项目利益有关者"之间就有关项目参数共识，提供书面文档。它论述以SOW为基础业务需求，并且把它转化成产品 模块实行信息。
简而言之, 这个阶段组建项目团体，保证客户实行项目成功。企业人员与客户人员一道，组建项目团体, 设定项目措施和范围，并建立项目管理控制。重要交付成果有，处理方案范围和项目管理控制。制定了项目质量检查计划。
1.1.1.2 需求分析阶段
在需求调研阶段, 在项目管理小组指导下, 由企业和客户构成统一项目团体将识别并且书面记录在开始设计客户处理方案之前所必须弄清晰，需处理问题。项目团体书写、提炼满足客户业务目所需功能和技术规定。重要交付技术成果为业务需求和差距分析。
专家服务顾问将进行一种配置检查，以保证系统有精确规格，便于购置硬件和架构布署。在有技术客户经理参与状况下, 通过完毕初始评估, 来建立布署基准，及通过给战略，管制，顾客采用, 流程和技术各方面打分评估来建立业务目。
1.1.1.3 项目设计阶段
在设计阶段, 重要目是设计一种可以最佳地满足客户明确业务需求处理方案，并且为培训和系统测试做准备。
在设计(Design)阶段,项目团体运用应用系统屏幕流程和设计布局来映射在发现阶段确定需求,设计处理方案原型。
重要交付技术成果是处理方案设计文档和测试方略。这个方略定义测试计划和测试规定，以保证一种系统布署成功。重要目是提供一种高级测试方略，以便使用自动化测试工具和/或手工过程来实现功能测试,系统整合测试(SIT),顾客验收测试 (UAT)和性能测试。
专家服务顾问要执行设计检查，来评估由客户或集成商提供书面设计文档，并且提供详细提议清单。设计原则包括,但不限于，应用系统性能,对升级影响,应用系统维护, 与数据模型有关问题和常规最佳做法。
1.1.1.4 项目开发阶段
在开发阶段，项目团体将开发应用系统, 提供任何需要扩展功能和外部接口, 为客户部门布署和持续支持处理方案做准备。项目团体配置应用系统、所有需要扩展功能和外部接口。重要交付技术成果有功能测试和系统测试。这些流程整合和测试活动更好地保证介入系统功能与客户组织业务需求协调一致。
专家服务顾问应当进行一种配置检查，来评估所有通过客户化改造实行文档。在这个检查过程中,所有这样文献都将被评估，以使应用系统性能, 应用系统升级,系统维护工作量和常规最佳实践最优。
1.1.1.5 项目验证阶段
在验证阶段, 将完毕新系统所有功能测试。这个阶段分两个部分。第一部分,项目团体进行一种对有生产数据应用系统所有功能进行测试。在这个检测完毕后,关键顾客然后进行一种代表性验收测试，以保证系统对地处理顾客需求。一旦全面功能测试结束, 将进行一种使用系统工具，严格性能测试。这一阶段重要交付技术成果为顾客验收测试和性能测试成果, 包括性能,容量和寿命测试。
适时性能调整审计，可保证整个企业架构环境性能最佳。在这个检查中, 专家服务将积极性地识别任何性能问题, 这样将减少在运行时出现问题风险，增长系统生产切换信心。在有技术客户经理参与状况下, 可执行一种实行准备就绪检查，以确认系统与否可以布署了。这个实行准备就绪检查是用来评估实行风险,技术上与否准备停当以及布署方略。
此时，应当召开管理人员定向协调研讨会，将责任转移给一线员工，这些员工将开始支持业务流程和技术推出。在管理人员定向协调研讨会上, 项目团体与客户管理团体一起工作，以获得维持资助人内部负责，并把对信号传达给组织其他组员。
1.1.1.6 布署上线阶段
布署上线阶段内第一种活动是实行一种投产导航。这个导航是被用来测试全面生产布署, 并且在客户业务环境中一部分部门中进行，例如一种地区或一种区域。生产导航在机构业务环境中部分部门里，为顾客提供所有系统特点。来自于生产导航反馈信息指导整个布署。
同样在这个过程中, 专家服务顾问应当进行生产准备就绪检查, 通过积极地识别任何也许导致布署中断和使实行系统处理方案技术长处打折扣所有问题，来协助系统顺利推出。
此时, 要召开流程实行研讨会，布署流程最优实践，来优化人, 流程和技术配合。目是在客户所有一线机构中，使用变革和销售流程最佳实践，使最初赞助人和行政领导团体完全满意。
1.1.2 项目管理方案
1.1.2.1 项目管理概述
项目管理包括在项目生命周期中协调所有项目管理知识领域所波及过程。它保证项目所有构成要素在对时间结合在一起，以成功完毕项目。进行项目整体管理时，必然波及项目范围、质量、时间和成本管理以及人力资源、沟通、风险管理等各个环节，项目管理一种复杂工程，在此重要针对南京银行企业服务总线项目项目进度管理、变更管理、沟通管理、质量管理、风险管理等有关方略进行描述。
1.1.2.2 项目进度管理
通过项目进度管理最终明确项目开发阶段进度控制活动和关键流程。
Ø 项目经理：
u 根据软件开发计划编制详细阶段开发计划以及每项任务边界时间，并召集过程控制人员、专题小组负责人审核该计划；
u 审核各专题小组拟订每项任务日程安排；
u 检查和控制项目进度；
u 制定进度变更计划；
Ø 过程控制人员：
u 协助审核详细阶段开发计划和任务边界时间；
u 监督项目进展；
Ø 专题小组负责人：
u 协助审核详细阶段开发计划和任务边界时间；
u 在听取小组组员意见基础上，拟订每一项任务日程安排；
u 负责检查和控制任务进度，并填写进度控制表；
u 负责制定任务变更计划。
1.1.2.2.1. 进度安排流程
Ø 项目经理根据项目计划，明确该阶段边界时间；
Ø 根据项目计划中任务PERT网络图，找出该阶段关键任务并深入分解、细化，在此基础上绘制更详细阶段任务PERT网络图；
Ø 拟订详细阶段计划；
Ø 确定每一关键任务边界时间；
Ø 召集各专题小组负责人审核拟订计划，并修改；
Ø 专题小组负责人确定任务日程安排；对于大型或时间规定严格项目，进度安排应以天为单位；
Ø 征求小组组员意见；
Ø 交由项目经理和过程管理人员审核。
1.1.2.2.2. 进度控制流程
Ø 项目经理和过程管理人员按照阶段PERT图，标志阶段中被跟踪关键任务和里程碑，并将之告知专题小组负责人；
Ø 专题小组负责人按照任务日程安排，确定任务完毕期间关键时间点，并将之告知专题小组组员；
Ø 专题小组负责人常常与组员沟通，理解任务进展；并定期检查，填写任务进度表和下期计划表，及时发现问题；
Ø 项目经理定期组织专题小组负责人，召开项目状态会议，理解任务进展，及时发现问题；项目过程管理人员参与会议或理解会议记录；
Ø 专题小组负责人在执行中发现延迟，分析原因：
u 人员紧张：组内调配不了，找项目经理处理；
u 事先预估局限性：调整任务日程安排；若处理不了，告知项目经理，会同过程管理人员，调整详细阶段计划；假如阶段内消化不了问题，则项目经理按照《配置管理程序》，变更软件开发计划。
1.1.2.3 项目变更管理
针对项目变更管理组织变更控制小组，由项目组经理、项目管理部人员、项目总监、客户、客户部组员构成，考虑并授权项目重大修改（修改工作量超过一周）。而项目经理负责项目一般修改决策（修改工作量在一天以上，一周以内）。
变更管理活动包括修改祈求、评估、通过、执行和跟踪。
变更管理要点如下：
Ø 变更同意权限：
Ø 变更控制组负责讨论和决策项目重大修改；
Ø 项目经理讨论和决策一般性修改；并报项目管理部立案；
Ø 修改审批程序：
Ø 根据不一样地点客户有不一样审批程序。
1.1.2.3.1. 变更状态登记
变更状态登记活动记录和汇报多种配置项状态，记录在项目生命周期中任何管理信息和历史信息。包括：所有变更祈求表、所有变更汇报单、所有变更记录。由项目管理人员存取状态登记。
变更状态登记目是为了控制软件需求发生变更时处理过程，使之按照制定规程进行，以保证软件需求一致性。
1.1.2.3.2. 变更管理流程
Ø 客户方或高伟达提出变更祈求，填写变更申请表；
Ø 将变更申请表交本项目组项目经理；
Ø 双方项目经理（或项目经理授权人，必须以书面形式确认）共同审阅，评估该需求变更技术有效性和对本项目影响；
Ø 假如审阅同意该祈求，则双方项目经理（或项目经理授权人，必须以书面形式确认）签字确认，变更申请表将被贵行文档管理员登记后，转发给高伟达。假如未获同意，其原因将反馈给该需求变更发起人；
Ø 高伟达在收到经审阅同意需求变更申请后三个工作日内，发给贵行一份书面确认书，确认其收到，并给出分析与执行变更所需时间和工作量估算；
Ø 根据祈求变更程度和复杂度，高伟达深入进行成本评估，若不需成本，则直接执行变更工作；若需要增长成本，则以书面形式告知贵行文档管理员，贵行管理员登记后，按照项目管理措施中项目变更管理流程处理。
1.1.2.4 项目沟通管理
南京银行ESB项目是一种技术与业务互动项目，项目成功很大程度上依赖于业务人员参与程度及技术人员对业务需求透彻分析，这就规定技术与业务人员保证充足交流，制定并遵守项目内部沟通管理计划。

1.1.2.4.1. 项目沟通形式
根据本项目组织形式及特点，我们提议采用如下多种方式沟通形式：
序号
沟通形式
负责人
沟通对象
内容
频度
输出文档
1
领导小组与项目组联络会议
领导小组组长
项目管理组、领导小组
项目实行状态汇报，问题汇报、提议措施并规定得到答复，项目组进行问题答复和传达领导组指示
每两周1次
会议纪要
2
总体组会议
项目总监、项目经理
总体组组员
总体组内部工作分工协调、布置，分析各专业组工作状况和提出问题决策，为与项目组联络会议作准备
每周1次
会议纪要
3
专业组组长会议
项目总监、项目经理
各专业组组长、总体组
专业组进行进展汇报、问题汇报及提议措施；总体组布署工作安排，决策，协调，分析进度、问题等
每周1次
会议纪要*
4
专业组内部会议
专业组组长
专业组组员
专业组内部交流会议，任务布置、信息交流、问题讨论等
每2～3天1次
/
5
动员大会
总体组、领导小组
全体人员
在全体项目组员范围内宣布项目总体和阶段目，回忆前阶段成果，鼓励士气
项目各阶段开始
/
6
简报
项目助理
全体人员
反应项目动态，包括进展状况、问题及处理方案，本周工作成果、下周工作重点等
每周1次
简报*
7
小组工作周报
专业组组长
总体组
反应各个专业组每周实际工作状况及成果，包括根据计划执行状况和进度偏差。
每周1次
小组工作周报*
8
个人工作周报
专业组组员
专业组组长
反应个人每周实际工作状况及成果，包括根据计划执行状况和进度偏差。
每周1次
个人工作周报
9
电子邮件
全体人员
当事人
需讨论问题非正式书面交流
按实际需求
电子邮件
10
平常交流
全体人员
当事人
需讨论问题非正式口头交流
按实际需求
/
备注：
1、“负责人”为各类沟通形式组织者；
2、“沟通对象”为需参与各类沟通项目干系人；
3、“输出文档”为各类沟通所产生书面文献，由各类沟通“负责人”或其指定人员制作并派发“沟通对象”；
4、“输出文档”一栏中有“*”记号文献需由项目办公室作为项目文献进行存档。
1.1.2.4.2. 会议管理制度
项目开始进行后来，要有效地控制项目，需要在各个关键时刻召开关键会议。关键会议重要内容是总结上一阶段工作，分析问题、提出提议，并简介下一阶段重要任务和目，使各有关人员都能做到心中有数，明确努力方向。关键会议也是协调各不一样小组之间人员以及工作任务重要手段。
除关键会议外，在项目进行全过程中，应定期召开例会，会上重要简介项目进展状况，检查进度、与否存在问题等，会议时须做详细会议记录并在会后报送所有项目有关人员。重要项目会议流程规定如下：
Ø 会前准备：
u 做好准备工作，如明确会议目和会议议程等；
u 把会议中规定讨论材料事先下发给开会组员；
u 提前两天告知各位与会组员；
u 准备会议环境、会议用设备等；
Ø 会议之中：
u 会议组员准时到会；
u 按会议议程逐项进行；
u 严格控制会议时间；
Ø 会后跟踪：
u 会议决策贯彻和检查。
1.1.2.5 项目质量管理
为保证项目顺利实行及系统质量，必须在项目管理过程和项目实行过程上加大质量管理力度。通过高伟达企业实行成功案例，我们深深体会到“质量是计划出来”这一现代质量学观点所蕴含深刻道理，因此，我们在项目启动及项目进展各个阶段都会仔细制定各项工作计划，严格按照审核通过计划进行项目控制。
针对本项目，我们提议从QA及QC两方面保障项目顺利实行，详细质量保障措施如下：
1.1.2.5.1. 质量保证
本项目将设置质量保证小组，由南京银行和高伟达企业各出一名人员担任QA角色，其工作任务是根据项目总体组制定质量查对单，在项目进展过程按照质量查对单逐项审核项目与否按照计划约定执行和控制，并直接向南京银行有关领导汇报项目实行质量状况。
1.1.2.5.2. 正式评审
根据本项目特点，本项目中将对项目计划、软件需求规格阐明书、系统设计阐明书、测试规格阐明书、测试汇报等文档，组织南京银行有关领导、专家进行正式评审，以便审核系统开发中各阶段所产生过程文档，以保证文档内容与上一阶段所产生软件文档内容一致，并且符合使用者需求。
1.1.2.5.3. 交叉审查
除项目规定正式评审内容外，本项目还将对各模块软件代码实行交叉评审制度。各模块负责人应根据总体组制定代码质量审核清单，对所负责检查其他模块软件代码进行仔细审查，对代码质量不能通过交叉评审则必须进行返工。整体软件代码交叉评审总量不能少于60％。
1.1.2.5.4. 变更控制
为保证软件产品质量，开发过程将严格采用配置管理工具进行变更控制，其目是保证最终软件产品可以符合业务需求各项规定，并对开发过程进行监控、汇报和提供征询支持，它包括下面质量属性规定：
Ø 软件产品与需求、阐明书和设计一致；
Ø 按照阐明原则建立文档；
Ø 可测试和可维护；
Ø 被识别、管理、评审和测试；
Ø 当变更发生时可管理。
1.1.2.6 项目风险管理
任何项目开发实行过程中都会碰到多种风险，在各方面都会碰到不一样规模风险，因此需要理解工程自身风险、技术 风险、新产品风险、工程资源风险、工程过程风险等全方位风险原因。通过对风险量化提供一种计划来管理防止风险，同步对于潜在风险也应当建立意外事件应急计划，使其在必要时可以以可控及有效方式作出反应。
ü 针对需求风险，南京银行应把握系统建设起点要高、规范运作为系统建设基础工程、采用构件化技术进行应哟软件开发、采用B/S技术减少信息点维护成本方式规避需求风险。
ü 针对合作风险，选择一种长期、上规模、具有成熟行业经验、项目管理规范、技术先进、员工有归属感、真正站在顾客立场上考虑问题企业作为后盾，高伟达集团是能为您最大程度地控制合作风险。
ü 针对资源风险，拥有健全组织与管理，在防止人员流动基础上，虽然因个人原因必须离职时，高伟达企业也因其规范、体系化管理与产品架构而使项目基本不受影响或很少受到影响。
ü 针对技术风险，高伟达银行业务系统拥有多种成功实践经验，具有与国外接轨理念与技术，同步拥有不停调整、更新技术体系、以及参照原则体系指定规范质量原则并在实行过程中加强阶段评审，使由于技术原因而也许导致风险减少到最小。
除此之外，为防止操作风险，在南京银行自身加强制度管理基础上，高伟达还提供培训考试合格上岗及定期培训定期总结分析模式来规避此类风险。
1.1.2.6.1. 风险管理内容
风险管理内容如下：
Ø 项目实行前和实行中对风险发现、识别、上报、分析及风险负责人指定；
Ø 风险应对计划制定和执行（应对计划包括两部分，一是在怎样减少风险发生机率规避计划；一是当风险不幸变成现实时，怎样应对应急预案）；
Ø 风险状态监控和更新；
Ø 定期对项目风险进行记录、分类和总体构造分析。
1.1.2.6.2. 风险管理中有关角色和责任
参与方
角色
职责
备注
风险识他人
项目有关任何人
汇报发现风险，填写风险登记表描述风险，注明风险严重度、风险发生机率和风险分类
假如是项目有关人员，提交至项目经理，假如是项目管理办公室人员，提交项目管理办公室主任

项目经理
项目内风险管理负责人
在项目进行中，管理项目内风险并提供项目内应对计划
对于无法在项目内处理风险，审核风险登记表，并确认风险描述、风险发生机率、风险负责人以及风险发生后应急预案
口头确认或书面承认上报风险登记表,将风险登记表发往对应部门

项目管理办公室
项目整体风险管理执行监督机构
在项目启动前，组织定义项目级别风险登记、评估和应对计划
在项目实行阶段，对项目报送有关风险登记表和应对计划进行审核，重点审核跨项目风险、严重度为中或中以上风险和发生机率为中或中以上风险,提议整个项目应对计划
根据对项目全社考虑，更改项目上报风险之严重度、发生机率和风险负责人
对于无法处理、风险严重度为中或中以上风险，负责上报项目总监
跟踪风险进展，对异常进展风险进行预警
定期记录分析项目风险，在项目周报和月报中提交风险记录状况

项目总监
风险管理最终决策机构
对重大风险，进行决策，给出最终处理意见

风险负责人
风险规避、应急预案执行负责人
填写风险登记表风险分析与行动计划
负责风险应对执行、并汇报风险状态变化

1.1.2.6.3. 风险严重程度
Ø 劫难：会由于无法满足需求而导致任务失败，会产生错误导致进度延迟和预算严重超支；
Ø 严重：会由于无法满足需求而导致系统性能下降，使得项目能否成功受到置疑，严重影响项目里程碑范围、交付日期和交付质量以及会影响其他项目进展风险；
Ø 轻微：会由于无法满足规定而导致次要任务退化，影响项目里程碑范围、交付日期和交付质量以及会影响其他项目进展但不严重风险；
Ø 可忽视：不影响或轻微影响项目里程碑范围、交付日期和交付质量风险，只是无法满足规定而导致使用不以便或不易操作。
1.1.2.6.4. 风险状态
Ø 已提交：风险识他人已填写风险登记表，完毕了风险号分派、风险描述并有项目经理提交；
Ø 拒绝：项目管理办公室认为风险导入人所提出风险不属于项目风险；
Ø 已完毕计划：风险负责人得到风险登记表后，对其进行分析并完毕应对计划；
Ø 规避计划：风险负责人正在根据应对计划规避风险；
Ø 风险已规避：风险负责人已成功规避风险并得到项目管理办公室承认；
Ø 发生进入应急计划：风险负责人未成功规避风险，风险发生，执行应急预案。
1.1.2.6.5. 风险分类
本项目中，风险重要分为如下几类：
Ø 管理类风险
项目管理没有遵照项目管理制度、时间、岗位规定。出现项目风险。
Ø 资源类风险
由于人力资源、设备环境等原因产生。例如，ATM设备没有驱动程序，无法进行程序调试。
Ø 业务类风险
业务风险重要表目前业务需求不清晰，变动频繁。
Ø 技术类风险
技术风险重要体目前技术架构不合理，各个子系统、服务渠道无法进行整合。
1.1.2.6.6. 风险管理流程
风险管理流程包括：
Ø 项目启动前风险识别与防备流程
在各项目启动前，应当由项目管理办公室指导各个项目提交其项目风险原因识别、评估和应对措施计划；
项目管理办公室根据各项目风险识别计划，以及其对项目风险理解，完毕项目风险原因识别、评估和规避项目风险规避计划以及制定项目风险应急预案；
项目管理办公室将有关风险应对计划上报项目总监审批；
将项目总监审批过风险应对计划提交给领导领导组审批；
审批通过风险应对计划由项目管理办公室公布归档；
在项目实行过程中由项目经理管理风险应对计划执行，项目管理办公室通过项目周、月报跟踪监督。
如下图示：

Ø 项目运行中风险管理流程
在项目实行过程中，所有项目组组员均有责任汇报进程中发现风险原因，并汇报项目经理；
项目经理在确定其确为风险后，定义风险发生机率和严重度并指定风险负责人，制定风险一旦发生应急预案，并将其填写风险登记表上报项目管理办公室；
项目管理办公室审核风险发生机率、严重度和风险负责人并负责风险状态监控；
风险负责人负责编制风险应对计划，并定期汇报风险状态；
项目管理办公室负责发现跨项目风险原因，并主持评估规避计划和应急预案；
项目管理办公室将有关风险评估汇报和规避计划、应急预案上报项目总监审批；
所有发现风险原因和审批通过对应风险应对计划由项目管理办公室公布归档；
在项目实行过程中由项目经理管理风险应对计划执行，项目管理办公室通过项目周、月报跟踪监督。
如下图示：

1.1.3 项目实行计划
1.1.3.1.1. 项目组织架构
有效组织构造，是项目成功有力保证。对于一种银行服务总线项目，除了考虑项目有效管理，也要考虑SOA类项目实行特点；根据本次项目范围和规定，项目参照组织构造如下

1.1.3.1.1.1 项目管理委员会
项目管理委员会负责监督并指导项目实行进程，定期审核项目经理就项目进展执行状况书面汇报，对项目中存在重大问题做出决策，协调处理重大问题和突发事件，决定对项目经理任免。项目管理委员会由南京银行高层领导与我司高层领导共同构成。
1.1.3.1.1.2 服务总线管理组
向项目管理委员会负责，在项目实行过程中进行服务原则和原则控制，在未来项目实行完毕后，由这个组织管理和同意新服务公布和渠道系统接入。同步负责制定企业实行SOA项目总体规划，从企业级高度而非项目级参与项目管理。服务总线管理组由南京银行架构师和我司企业架构师共同构成。项目实行完毕后职责交给客户执行。
1.1.3.1.1.3 项目管理组
负责向项目管理委员会定期汇报项目进展状况，就项目中存在问题提出处理提议，对项目进行有计划地组织管理，并检查项目进展状况。项目管理组由南京银行项目负责人和我司项目经理和技术负责人共同构成。
1.1.3.1.1.4 基础架构组
负责基础架构设计和流程建模设计。和企业架构师共同设计整体基础架构，完毕本项目范围内规划，考虑本项目与整个企业范围IT架构一致性规划。
1.1.3.1.1.5 质量管理组
直接从属项目管理委员会，按制定原则及控制手段执行进度管理，风险管理，全面执行各项局方及业内规定质量原则和工作流程。
1.1.3.1.1.6 服务定义公布组
负责在总线上公布服务和设定服务原则。根据基础架构规划中服务架构，对服务进行归类，根据服务定义模板，完毕服务识别、设定和在服务总线上公布和配置。
1.1.3.1.1.7 基础组件开发组
负责基础，公共组件统一开发；开发从日志，安全到多种便利工具公共组件，完毕在OSB之上多种组件扩展工作，如扩展函数，扩展报文转换措施，扩展监控处理模块，进行监控平台集成等。
1.1.3.1.1.8 测试组
负责系统联合测试工作，在项目质量方针指导下，进行测试管理，制定设计系统测试计划、测试方案、测试案例、各项测试、形成测试汇报并对测试成果进行跟踪，包括不一样阶段测试工作。
1.1.3.1.2. 实行人员名单
1.1.3.1.3. 实行人员简历
1.1.3.1.4. 项目实行阶段划分
根据我企业执行ISO9001:质量管理体系规定，将整个项目实行过程划分为：需求分析、详细设计、系统开发、系统测试、试运行、系统验收六个过程；项目监控、管理过程分为：配置管理、内部监理和项目变更管理三个过程。下面将针对以上六个实行过程和三个管理过程实行计划即项目计划进行简介。
1.1.3.1.4.1 第一阶段：需求分析阶段
自协议签定之日，与项目筹办小组并行完毕业务需求分析，建立完善项目组织机构，双方亲密协作，各项目小组亲密协作，各项工作同步有条不紊地展开。
Ø 完毕并提交项目计划书，产品管理计划，质量控制计划；
Ø 详细需求分析。需求分析计划和措施重要包括调研阶段划分、日程安排、调研形式和内容、调研过程和成果文档模板、资源安排、顾客方规定等内容；
Ø 企业方与顾客方进行应用软件需求讨论、研究和分析，并一起根据需求调研分析汇报和调研多种成果编写《软件需求规格阐明书》，对应用系统提出完整、精确、清晰、详细规定，重要是需求框架和基本要素，并进行正式评审；
时间跨度：6周
需要资源（专职）：行方科技部2名、高伟达企业项目组需求分析人员3人。
1.1.3.1.4.2 第二阶段：系统设计阶段
Ø 根据《软件需求规格阐明书》，进行应用软件概要设计，设计系统整体构造、重要流程、有关模块接口以及数据库设计，定义详细设计和编码规范，整顿《概要设计阐明书》；
Ø 根据《软件需求规格阐明书》和《概要设计阐明书》，由开发小组组长负责组织进行详细设计分析讨论，完毕交易流程设计和报表设计等，整顿《详细设计阐明书》；
Ø 编写系统构造设计、功能设计、数据库构造及数据库设计、系统内外接口及界面设计、系统出错处理及安全保障设计、代码数据设计、联机交易流程以及批处理交易流程等设计文档；
Ø 启动数据转换工作，定义统一中间格式。
时间跨度：6周
需要资源（专职）：行方科技部2名、高伟达企业现场8名技术、业务骨干，产品征询1名。
1.1.3.1.4.3 第三阶段：系统开发阶段
与系统设计阶段对应，是系统开发阶段，企业服务总线建设是基于ORACLE成熟总线产品OSB，因此在进行了周密严格需求分析及详细设计前提下，真正需要开发工作并不多，周期对应较短。
Ø 在系统设计完毕后，由企业项目实行团体开发人员根据多种设计文档进行应用软件编码工作；
Ø 系统开发工作完毕及培训准备工作完毕后，即开始进入全面培训阶段；
Ø 系统开发工作完毕后，进行应用软件单元测试和系统集成测试；
时间跨度：2周
需要资源：行方科技部1名、高伟达企业现场设计开发人员、测试人员10名。
1.1.3.1.4.4 第四阶段：系统测试阶段
系统开发完毕后进行系统测试工作。本阶段重要指在南京银行建立测试环境中，进行全面模拟测试，完毕系统功能测试，由于测试重要性，估计将花费两个月左右时间来完毕对系统模拟测试。
Ø 测试对象是编程结束时提交内容；
Ø 制定测试计划和选定测试措施、准备测试数据、确认测试环境（应当是硬件系统通过初步验收后所构成原则模式运行环境）；
Ø 进行测试记录；
Ø 处理测试发现问题，分析测试成果，形成测试汇报；
Ø 为测试后确实认和初步验收做好准备。
Ø 验收测试：在系统试运行一段时间后，由验收小组组织进行全面系统验收测试，以证明系统合格性。系统验收工作，系统验收详见《验收和测试》有关章节。
时间跨度：8周
需要资源：行方科技部3名、接入系统有关人员1名、高伟达企业现场8名技术、业务骨干。
1.1.3.1.4.5 第五阶段：试运行阶段
模拟测试完毕，进入系统试运行阶段。考虑到试运行期间目，是将通过集成测试及性能测试后较为稳定版本投入到实际工作环境中运行，用于检查系统与否完全满足实际业务需要，为新系统上线运行做准备。
Ø 系统上机联调；
Ø 试运行期间，核查新系统与否满足实际业务需求；
Ø 试运行期间发现问题，进行记录、调整、处理；
Ø 试运行期间还是测试良好时机，在该阶段，应对各网点设备、网络状况、业务响应时间等内容进行测试。
时间跨度：4周
需要资源：行方科技部1名、接入系统有关人员1名、高伟达企业现场4名技术、业务骨干。
1.1.3.1.4.6 第六阶段：上线验收及维护阶段
上线验收阶段重要工作是制定详细上线计划，确认上线环节。选择合适日期开始上线实行工作，做好外连系统和外围系统预前告知和公告工作。
时间跨度：24周
需要资源：行方有关人员2名、高伟达企业现场2名技术、业务骨干。
1.1.3.1.4.7 并行管理阶段一：配置管理工作
配置管理工作内容重要是对配置项控制。配置项重要包括：技术文档（技术文档分文字类和表格类两种）、项目实行阶段状态表。配置工作包括：文档一致性控制、文档标识控制、项目实行阶段控制、项目实行更改控制。
时间跨度：26周
需要资源：科技部1名、高伟达企业现场1名配置管理人员。
1.1.3.1.4.8 并行管理阶段二：内部监理工作
对项目实行进程、成本、工期、进行监控过程。
时间跨度：26周
需要资源：行方科技部1名、高伟达企业现场1名QA人员。
1.1.3.1.4.9 并行管理阶段三：项目变更工作
涵盖软件实行项目实行过程中顾客需求变更及阶段性成果变更处理。包括需求分析、详细设计、系统开发、系统测试、系统维护、系统交付、系统验收各阶段变更以及波及项目管理变更。
1.1.3.1.5. 项目实行周期计划
整个项目实行周期计划如下：
项目阶段
起始
时间
结束
时间
需求分析阶段
产品培训
T
T+5
需求梳理
T+6
T+13
需求分析
T+14
T+28
需求评审
T+29
T+30
系统设计阶段
概要设计
T+31
T+43
详细设计
T+44
T+57
设计评审
T+58
T+60
系统开发阶段
应用开发
T+61
T+70
单元测试
T+71
T+80
集成测试、顾客验收测试环境准备
T+71
T+80
系统测试阶段
集成测试
T+81
T+90
顾客验收测试
T+91
T+100
性能测试
T+101
T+120
系统试运行上线
系统培训
T+121
T+125
系统运行环境准备
T+126
T+130
上线
T+131
T+133
系统试运行
试运行总结
T+134
T+150
项目验收

1.1.4 项目测试方案
1.1.4.1 测试目
对系统进行集成测试。对测试范围内需要测试特性进行“完整性”、“精确性”、“有效性”、“可靠性”、“稳定性”验证并对性能指标进行测评。
通过本次测试，到达如下详细目：
1) 保证软件基本功能使用正常，严重缺陷率不不小于5%；
2) 保证系统可靠稳定运行；
3) 保证项目有关文档符合CMMI 3级文档规范。
1.1.4.2 测试对象
1. 系统具有总线基本功能如：协议转换、交易路由、数据转换；
2. 服务封装规范满足行内存量、增量业务系统；
3. 对各类系统提供适配器功能满足性；
4. 系统并发处理能力及响应时间满足规定；
5. 系统可靠性、稳定性。
1.1.4.3 测试范围
测试范围最终以实际形成《系统业务需求阐明书》内容为准。
1.1.4.4 测试措施
1.1.4.4.1. 功能测试
配合开发组开发过程分阶段提供测试小结,测试措施以原则黑盒技术为主。
本次测试过程中，功能测试执行环节分为两个阶段，详细描述如下：
阶段名称
详细措施
目
阶段一
1. 执行测试用例中“基本场景”用例，验证系统基本功能使用正常；
2. 保证系统执行正常操作时，数据输入输出流转正常（使用正常、有效数据）。
保障软件正操操作时功能正常
阶段二
执行测试用例中“异常场景”用例。

保证系统异常操作时，系统强健性有一定保障，（使用异常数据）。
回归测试
1. 对“阶段一”、“阶段二”发现并被修正缺陷进行再次测试；
2. 抽样执行测试用例中“异常场景”用例。
保障软件缺陷遗留率不不小于5%
1.1.4.4.2. 性能测试
分为负载测试、压力测试、稳定性测试等三个阶段。使用LoadRunner进行测试。根据性能测试调研得到数据构建业务模型，进而构建测试模型。测试模型包括多种子类型，不一样类型测试模型应用于不一样类型性能测试。
性能测试模型包括要素如下：
测试模型子类型
所含业务
并发顾客数
思索时间
单业务压力测试模型1

单业务压力测试模型2

……

混合业务压力测试模型

压力测试模型

稳定性测试模型

本次测试包括性能测试类型如下：
1) 压力测试
基于本次测试目和需要测试特性，将本次测试分为两个阶段：阶段一，单业务压力测试；阶段二，多业务混合压力测试。
a) 单业务压力测试
测试目：
排查各个经典业务压力瓶颈。
选用测试模型
单业务压力测试模型。
b) 混合业务压力测试
测试目：
在排查各个经典业务性能瓶颈后，测试该系统最大并发顾客数，并找到系统存在性能瓶颈。
选用测试模型：
混合业务压力测试模型。
2) 稳定性测试
测试目：
检查系统在持续运行240小时过程中性能体现
选用测试模型：
稳定性测试模型。
1.1.4.4.3. 文档测试
对需求阐明书、设计文档进行规范性检查。
1.1.4.5 测试用例
本次测试中将重要测试用例归类为不一样测试场景，同步设计易用性测试用例和接受测试用例。
1.1.4.5.1. 基本测试场景
描述系统正常操作流程，以通过操作完整实现一种业务功能为原则。其中每一种环节对应一种测试用例。测试用例中采用数据都为正常数据。
1.1.4.5.2. 异常测试场景
基于系统正常操作流程，在整实现一种业务功能操作过程中验证系统数据校验、特殊操作处理等功能。其中每一种环节对应一种测试用例。测试用例中采用数据有正常数据和异常数据。
1.1.4.5.3. 接受测试用例
由“基本测试场景”中选用出代表性用例，用于验证开发团体提交测试版本可测性。
1.1.4.6 人员及职责
资源
职责描述
数量
到位时间
测试项目负责人
1. 负责测试人员组织和管理工作，并指导、带领本组人员平常测试工作；
2. 负责对各个项目做测试需求分析和文档整顿工作;
3. 参与执行测试用例
1
测试小组进场时
配置管理员
负责测试文档和测试工具管理工作
1
测试开始执行前
质量管理员
负责检查测试过程中各个环节测试质量
测试开始执行前
测试工程师
1. 参与编写测试用例；
2. 负责功能、性能测试用例执行。
若干
测试开始执行前

1.1.4.7 测试工作输出
分类
名称
描述
输出人
备 注
文档
《测试方案》
Word
测试项目负责人

《测试进度计划》
project
测试项目负责人

《性能测试方案》
Word
测试项目负责人

《测试用例》
QCS/Excel　
测试组

《