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
测试项目责任人

《