《IT项目实施与管理方案-投标书(1).docx》由会员分享，可在线阅读，更多相关《IT项目实施与管理方案-投标书(1).docx（45页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、1.1 项目实施与管理1.1.1 项目实施方法论针对南京银行企业服务总线系统项目，高伟达公司基于对客户需求、业务目标、业务能力和IT环境的理解，结合多年的软件开发和系统实施经验，将项目的实施周期划分为六个活动阶段，保证在项目生命周期内，应用合理的项目管理和控制技术。通过专注于使客户投资回报最大化，和使客户的投资风险最小化的关键战略和战术领域，加快项目实施速度，使得项目成功地完成。这些阶段的特性是可循环往复性，使客户可以尽快地获得新的应用系统所带来的好处。1.1.1.1 项目定义阶段在这个阶段, 所有与分期实施相关的项目活动都被明确定义, 项目的项目利益相关者被指定，项目经理和客户项目经理的角色
2、和职责被传达给所有的项目利益相关者。管理项目所需的项目控制结构被定义,所有需要的项目规划文件被创建, 客户的业务问题和被用来衡量项目成功的衡量标准被确认。制定解决方案范围，在一个高级别上定义哪些模块将被实施，估算预期需要的客户化程度, 以及勾画出在产品之外需要开发的内容和要提交的技术成果。解决方案范围文档包括解决方案范围概述, 功能范围, 流程范围, 客户化问题, 其他风险, 外部依赖条件以及假设。这个工作为未来项目决策, 统一或达成项目利益相关者之间就有关项目参数的共识，提供书面的文档。它阐述以SOW为基础的业务需求，并且把它转化成产品 模块实施信息。简而言之, 这个阶段组建项目团队，保证客
3、户实施项目的成功。公司人员与客户人员一道，组建项目团队, 设定项目方法和范围，并建立项目管理控制。主要交付的成果有，解决方案范围和项目管理控制。制定了项目质量检查计划。1.1.1.2 需求分析阶段在需求调研阶段, 在项目管理小组的指导下, 由公司和客户组成的统一的项目团队将识别并且书面记录在开始设计客户解决方案之前所必须弄清楚的，需处理的问题。项目团队书写、提炼满足客户业务目标所需的功能和技术要求。主要交付的技术成果为业务需求和差距分析。专家服务顾问将进行一个配置检查，以保证系统有精确的规格，便于购买硬件和架构部署。在有技术客户经理参与的情况下, 通过完成初始的评估, 来建立部署的基准，及通过
4、给战略，管制，用户采用, 流程和技术各方面打分的评估来建立业务目标。1.1.1.3 项目设计阶段在设计阶段, 主要的目标是设计一个能够最佳地满足客户明确的业务需求的解决方案，并且为培训和系统测试做准备。在设计(Design)阶段,项目团队利用应用系统屏幕流程和设计布局来映射在发现阶段确定的需求,设计解决方案的原型。主要交付的技术成果是解决方案设计文档和测试策略。这个策略定义测试计划和测试要求，以保证一个系统部署的成功。主要的目的是提供一个高级的测试策略，以便使用自动化的测试工具和/或手工过程来实现功能测试,系统整合测试(SIT),用户验收测试 (UAT)和性能测试。专家服务顾问要执行设计检查，
5、来评估由客户或集成商提供的书面设计文档，并且提供详细的建议清单。设计标准包括,但不限于，应用系统性能,对升级的影响,应用系统维护, 与数据模型相关的问题和常规的最佳做法。1.1.1.4 项目开发阶段在开发阶段，项目团队将开发应用系统, 提供任何需要的扩展功能和外部接口, 为客户部门部署和持续支持解决方案做准备。项目团队配置应用系统、所有需要的扩展功能和外部接口。主要交付的技术成果有功能测试和系统测试。这些流程整合和测试活动更好地保证介入的系统功能与客户组织的业务需求协调一致。专家服务顾问应该进行一个配置检查，来评估所有经过客户化改造的实施文档。在这个检查过程中,所有这样的文件都将被评估，以使应
6、用系统性能, 应用系统升级,系统维护工作量和常规最佳实践最优。1.1.1.5 项目验证阶段在验证阶段, 将完成新系统全部功能的测试。这个阶段分两个部分。第一部分,项目团队进行一个对有生产数据的应用系统的全部功能进行测试。在这个检测完成后,关键用户然后进行一个代表性的验收测试，以保证系统正确地处理用户的需求。一旦全面的功能测试结束, 将进行一个使用系统工具的，严格的性能测试。这一阶段主要交付的技术成果为用户验收测试和性能测试结果, 包括性能,容量和寿命测试。适时的性能调整审计，可保证整个企业架构环境的性能最佳。在这个检查中, 专家服务将主动性地识别任何性能问题, 这样将减少在运行时出现问题的风险
7、，增加系统生产切换的信心。在有技术客户经理参与的情况下, 可执行一个实施准备就绪检查，以确认系统是否可以部署了。这个实施准备就绪检查是用来评估实施风险,技术上是否准备停当以及部署策略。此时，应该召开管理人员定向协调研讨会，将责任转移给一线的员工，这些员工将开始支持业务流程和技术的推出。在管理人员定向协调研讨会上, 项目团队与客户的管理团队一起工作，以获得维持资助人的内部负责，并把正确的信号传达给组织的其他成员。1.1.1.6 部署上线阶段部署上线阶段内的第一个活动是实施一个投产导航。这个导航是被用来测试全面的生产部署, 并且在客户业务环境中的一部分部门中进行的，例如一个地区或一个区域。生产导航
8、在机构的业务环境中部分部门里，为用户提供所有系统的特点。来自于生产导航的反馈信息指导整个的部署。同样在这个过程中, 专家服务顾问应该进行生产准备就绪检查, 通过主动地识别任何可能造成部署中断和使实施的系统解决方案的技术优点打折扣的所有问题，来协助系统的顺利推出。此时, 要召开流程实施研讨会，部署流程最优实践，来优化人, 流程和技术的配合。目的是在客户所有的一线机构中，使用变革和销售流程的最佳实践，使最初的赞助人和行政领导团队完全满意。1.1.2 项目管理方案1.1.2.1 项目管理概述项目管理包括在项目生命周期中协调所有项目管理知识领域所涉及的过程。它确保项目所有的组成要素在正确的时间结合在一
9、起，以成功的完成项目。进行项目整体管理时，必定涉及项目的范围、质量、时间和成本管理以及人力资源、沟通、风险管理等各个环节，项目管理一个复杂的工程，在此主要针对南京银行企业服务总线项目的项目进度管理、变更管理、沟通管理、质量管理、风险管理等相关策略进行描述。1.1.2.2 项目进度管理通过项目进度的管理最终明确项目开发阶段的进度控制活动和关键流程。 项目经理：u 根据软件开发计划编制详细的阶段开发计划以及每项任务的边界时间，并召集过程控制人员、专题小组负责人审核该计划；u 审核各专题小组拟订的每项任务的日程安排；u 检查和控制项目进度；u 制定进度变更计划； 过程控制人员：u 协助审核详细的阶段
10、开发计划和任务边界时间；u 监督项目进展； 专题小组负责人：u 协助审核详细的阶段开发计划和任务边界时间；u 在听取小组成员意见的基础上，拟订每一项任务的日程安排；u 负责检查和控制任务的进度，并填写进度控制表；u 负责制订任务变更计划。1.1.2.2.1. 进度安排流程 项目经理根据项目计划，明确该阶段的边界时间； 根据项目计划中的任务PERT网络图，找出该阶段的关键任务并进一步分解、细化，在此基础上绘制更具体的阶段任务PERT网络图； 拟订详细的阶段计划； 确定每一关键任务的边界时间； 召集各专题小组负责人审核拟订的计划，并修改； 专题小组负责人确定任务的日程安排；对于大型的或时间要求严格
11、的项目，进度安排应以天为单位； 征求小组成员的意见； 交由项目经理和过程管理人员审核。1.1.2.2.2. 进度控制流程 项目经理和过程管理人员按照阶段PERT图，标志阶段中被跟踪的关键任务和里程碑，并将之告知专题小组负责人； 专题小组负责人按照任务的日程安排，确定任务完成期间的关键时间点，并将之告知专题小组成员； 专题小组负责人经常与成员沟通，了解任务进展；并定期检查，填写任务进度表和下期计划表，及时发现问题； 项目经理定期组织专题小组负责人，召开项目状态会议，了解任务进展，及时发现问题；项目过程管理人员参加会议或了解会议的记录； 专题小组负责人在执行中发现延迟，分析原因：u 人员紧张：组内
12、调配不了的，找项目经理解决；u 事先预估不足：调整任务日程安排；若解决不了，告知项目经理，会同过程管理人员，调整详细的阶段计划；如果阶段内消化不了的问题，则项目经理按照配置管理的程序，变更软件开发计划。1.1.2.3 项目变更管理针对项目变更管理组织变更控制小组，由项目组经理、项目管理部人员、项目总监、客户、客户部成员组成，考虑并授权项目的重大修改（修改工作量超过一周的）。而项目经理负责项目的一般修改决策（修改工作量在一天以上，一周以内）。变更管理活动包括修改请求、评估、通过、执行和跟踪。变更管理要点如下： 变更批准权限： 变更控制组负责讨论和决策项目的重大修改； 项目经理讨论和决策一般性修改
13、；并报项目管理部备案； 修改审批程序： 根据不同地点的客户有不同的审批程序。1.1.2.3.1. 变更状态登记变更状态登记活动记录和报告各种配置项的状态，记录在项目生命周期中的任何管理信息和历史信息。包括：所有变更请求表、所有变更报告单、所有变更记录。由项目管理人员存取状态登记。变更状态登记的目的是为了控制软件需求发生变更时的处理过程，使之按照制定的规程进行，以保证软件需求的一致性。1.1.2.3.2. 变更管理流程 客户方或高伟达提出变更请求，填写变更申请表； 将变更申请表交本项目组的项目经理； 双方项目经理（或项目经理授权人，必须以书面形式确认）共同审阅，评估该需求变更的技术有效性和对本项
14、目的影响； 如果审阅批准该请求，则双方项目经理（或项目经理授权人，必须以书面形式确认）签字确认，变更申请表将被贵行文档管理员登记后，转发给高伟达。如果未获批准，其原因将反馈给该需求变更发起人； 高伟达在收到经审阅批准的需求变更申请后的三个工作日内，发给贵行一份书面确认书，确认其收到，并给出分析与执行变更所需时间和工作量的估算； 根据请求的变更程度和复杂度，高伟达进一步进行成本评估，若不需成本，则直接执行变更工作；若需要增加成本，则以书面形式通知贵行文档管理员，贵行管理员登记后，按照项目管理办法中的项目变更管理流程处理。1.1.2.4 项目沟通管理南京银行ESB项目是一个技术与业务互动的项目，项
15、目的成功很大程度上依赖于业务人员的参与程度及技术人员对业务需求的透彻分析，这就要求技术与业务人员保证充分的交流，制定并遵守项目内部的沟通管理计划。1.1.2.4.1. 项目沟通形式根据本项目的组织形式及特点，我们建议采取如下多种方式的沟通形式：序号沟通形式负责人沟通对象内容频度输出文档1领导小组与项目组的联系会议领导小组组长项目管理组、领导小组项目实施状态汇报，问题报告、建议措施并要求得到回复，项目组进行问题回复和传达领导组指示每两周1次会议纪要2总体组会议项目总监、项目经理总体组成员总体组内部工作分工协调、布置，分析各专业组工作情况和提出的问题决策，为与项目组的联系会议作准备每周1次会议纪要
16、3专业组组长会议项目总监、项目经理各专业组组长、总体组专业组进行进展汇报、问题汇报及建议措施；总体组部署工作安排，决策，协调，分析进度、问题等每周1次会议纪要*4专业组内部会议专业组组长专业组组员专业组内部交流会议，任务布置、信息交流、问题讨论等每23天1次/5动员大会总体组、领导小组全体人员在全体项目成员范围内宣布项目总体和阶段目标，回顾前阶段成果，激励士气项目各阶段的开始/6简报项目助理全体人员反映项目动态，包括进展情况、问题及解决方案，本周工作成果、下周工作重点等每周1次简报*7小组工作周报专业组组长总体组反映各个专业组每周实际工作情况及结果，包括根据计划的执行情况和进度偏差。每周1次小
17、组工作周报*8个人工作周报专业组组员专业组组长反映个人每周实际工作情况及结果，包括根据计划的执行情况和进度偏差。每周1次个人工作周报9电子邮件全体人员当事人需讨论问题的非正式书面交流按实际需求电子邮件10日常交流全体人员当事人需讨论问题的非正式口头交流按实际需求/备注：1、“负责人”为各类沟通形式的组织者；2、“沟通对象”为需参与各类沟通的项目干系人；3、“输出文档”为各类沟通所产生的书面文件，由各类沟通的“负责人”或其指定人员制作并派发“沟通对象”；4、“输出文档”一栏中有“*”记号的文件需由项目办公室作为项目文件进行存档。1.1.2.4.2. 会议管理制度项目开始进行以后，要有效地控制项目
18、，需要在各个关键时刻召开关键会议。关键会议的主要内容是总结上一阶段的工作，分析问题、提出建议，并介绍下一阶段的主要任务和目标，使各有关人员都能做到心中有数，明确努力的方向。关键会议也是协调各不同小组之间的人员以及工作任务的重要手段。除关键会议外，在项目进行的全过程中，应定期召开例会，会上主要介绍项目进展情况，检查进度、是否存在问题等，会议时须做详细的会议记录并在会后报送所有项目相关人员。主要的项目会议流程规定如下： 会前准备：u 做好准备工作，如明确会议目的和会议议程等；u 把会议中要求讨论的材料事先下发给开会成员；u 提前两天通知各位与会成员；u 准备会议环境、会议用设备等； 会议之中：u
19、会议成员准时到会；u 按会议议程逐项进行；u 严格控制会议时间； 会后跟踪：u 会议决议落实和检查。1.1.2.5 项目质量管理为保证项目顺利实施及系统质量，必须在项目管理过程和项目实施过程上加大质量管理力度。通过高伟达公司实施的成功案例，我们深深体会到“质量是计划出来的”这一现代质量学观点所蕴含的深刻道理，所以，我们在项目启动及项目进展的各个阶段都会仔细制定各项工作计划，严格按照审核通过的计划进行项目控制。针对本项目，我们建议从QA及QC两方面保障项目的顺利实施，具体的质量保障措施如下：1.1.2.5.1. 质量保证本项目将设置质量保证小组，由南京银行和高伟达公司各出一名人员担任QA的角色，
20、其工作任务是根据项目总体组制定的质量核对单，在项目进展过程按照质量核对单逐项审核项目是否按照计划约定执行和控制，并直接向南京银行的相关领导汇报项目实施的质量状况。1.1.2.5.2. 正式评审根据本项目的特点，本项目中将对项目计划、软件需求规格说明书、系统设计说明书、测试规格说明书、测试报告等文档，组织南京银行相关领导、专家进行正式评审，以便审核系统开发中各阶段所产生的过程文档，以保证文档内容与上一阶段所产生的软件文档内容一致，并且符合使用者的需求。1.1.2.5.3. 交叉审查除项目要求的正式评审内容外，本项目还将对各模块软件代码实行交叉评审制度。各模块负责人应根据总体组制定的代码质量审核清
21、单，对所负责检查的其他模块软件代码进行仔细审查，对代码质量不能通过交叉评审的则必须进行返工。整体的软件代码交叉评审总量不能少于60。1.1.2.5.4. 变更控制为保证软件产品质量，开发过程将严格采用配置管理工具进行变更控制，其目的是保证最终软件产品能够符合业务需求的各项要求，并对开发过程进行监控、报告和提供咨询支持，它包括下面的质量属性要求： 软件产品与需求、说明书和设计一致； 按照说明的标准建立文档； 可测试和可维护； 被识别、管理、评审和测试； 当变更发生时可管理。1.1.2.6 项目风险管理任何项目开发实施过程中都会遇到各种风险，在各方面都会遇到不同规模的风险，因此需要了解工程本身的风
22、险、技术 风险、新产品的风险、工程资源风险、工程过程风险等全方位的风险因素。通过对风险的量化提供一个计划来管理预防风险，同时对于潜在的风险也应该建立意外事件的应急计划，使其在必要时能够以可控的及有效的方式作出反应。 针对需求风险，南京银行应把握系统建设起点要高、规范运作为系统建设的基础工程、采用构件化技术进行应哟软件开发、采用B/S技术降低信息点维护成本的方式规避需求风险。 针对合作风险，选择一个长久的、上规模、具备成熟行业经验、项目管理规范、技术先进、员工有归属感、真正站在用户的立场上考虑问题的公司作为后盾，高伟达集团是能为您最大限度地控制合作风险。 针对资源风险，拥有健全的组织与管理，在避
23、免人员流动的基础上，即使因个人原因必须离职时，高伟达公司也因其规范的、体系化的管理与产品架构而使项目基本不受影响或极少受到影响。 针对技术风险，高伟达的银行业务系统拥有多个成功实践经验，具备与国外接轨的理念与技术，同时拥有不断调整、更新的技术体系、以及参照标准体系指定规范质量标准并在实施过程中加强阶段评审，使因为技术原因而可能导致的风险降低到最小。除此之外，为预防操作风险，在南京银行自身加强制度管理的基础上，高伟达还提供培训考试合格上岗及定期培训定期总结分析的模式来规避此类风险。1.1.2.6.1. 风险管理内容风险管理的内容如下： 项目实施前和实施中对风险的发现、识别、上报、分析及风险责任人
24、的指定； 风险应对计划的制订和执行（应对计划包括两部分，一是在如何降低风险发生机率的规避计划；一是当风险不幸变成现实时，如何应对的应急预案）； 风险状态的监控和更新； 定期对项目风险进行统计、分类和总体结构分析。1.1.2.6.2. 风险管理中的相关角色和责任参与方角色职责备注风险识别人项目相关的任何人报告发现的风险，填写风险登记表描述风险，注明风险严重度、风险发生机率和风险分类如果是项目相关人员，提交至项目经理，如果是项目管理办公室人员，提交项目管理办公室主任项目经理项目内风险管理负责人在项目进行中，管理项目内的风险并提供项目内的应对计划对于无法在项目内解决的风险，审核风险登记表，并确认风险
25、描述、风险发生机率、风险责任人以及风险发生后的应急预案口头确认或书面认可上报的风险登记表,将风险登记表发往相应部门项目管理办公室项目整体风险管理的执行监督机构在项目启动前，组织定义项目级别的风险登记、评估和应对计划在项目实施阶段，对项目报送的相关风险登记表和应对计划进行审核，重点审核跨项目的风险、严重度为中或中以上的风险和发生机率为中或中以上的风险,建议整个项目的应对计划根据对项目全社的考虑，更改项目上报风险之严重度、发生机率和风险责任人对于无法解决、风险严重度为中或中以上的风险，负责上报项目总监跟踪风险进展，对异常进展的风险进行预警定期统计分析项目风险，在项目周报和月报中提交风险统计情况项目
26、总监风险管理最终决策机构对重大风险，进行决策，给出最终处理意见风险责任人风险规避、应急预案执行的负责人填写风险登记表的风险分析与行动计划负责风险应对的执行、并汇报风险状态变化1.1.2.6.3. 风险严重程度 灾难的：会因为无法满足需求而导致任务失败，会产生错误导致进度延迟和预算严重超支； 严重的：会因为无法满足需求而导致系统性能下降，使得项目能否成功受到置疑，严重影响项目里程碑的范围、交付日期和交付质量以及会影响其它项目进展的风险； 轻微的：会因为无法满足要求而导致次要任务的退化，影响项目里程碑的范围、交付日期和交付质量以及会影响其它项目进展的但不严重的风险； 可忽略的：不影响或轻微影响项目
27、里程碑的范围、交付日期和交付质量的风险，只是无法满足要求而导致使用不方便或不易操作。1.1.2.6.4. 风险状态 已提交：风险识别人已填写风险登记表，完成了风险号分配、风险描述并有项目经理提交； 拒绝：项目管理办公室认为风险导入人所提出的风险不属于项目风险； 已完成计划：风险责任人得到风险登记表后，对其进行分析并完成应对计划； 规避计划：风险责任人正在根据应对计划规避风险； 风险已规避：风险责任人已成功规避风险并得到项目管理办公室认可； 发生进入应急计划：风险责任人未成功规避风险，风险发生，执行应急预案。1.1.2.6.5. 风险分类本项目中，风险主要分为以下几类： 管理类风险项目管理没有遵
28、循项目管理的制度、时间、岗位的要求。出现项目的风险。 资源类风险由于人力资源、设备环境等原因产生。例如，ATM设备没有驱动程序，无法进行程序调试。 业务类风险业务风险主要表现在业务需求不清晰，变动频繁。 技术类风险技术风险主要体现在技术架构不合理，各个子系统、服务渠道无法进行整合。1.1.2.6.6. 风险管理流程风险管理流程包括： 项目启动前风险识别与防范流程在各项目启动前，应当由项目管理办公室指导各个项目提交其项目风险因素识别、评估和应对措施计划；项目管理办公室根据各项目的风险识别计划，以及其对项目风险的理解，完成项目风险因素识别、评估和规避的项目风险规避计划以及制订项目风险应急预案；项目
29、管理办公室将有关风险应对计划上报项目总监审批；将项目总监审批过的风险应对计划提交给领导领导组审批；审批通过的风险应对计划由项目管理办公室公布归档；在项目实施过程中由项目经理管理风险应对计划的执行，项目管理办公室通过项目周、月报跟踪监督。如下图示： 项目运行中风险管理流程在项目实施过程中，所有项目组成员均有责任报告进程中发现的风险因素，并报告项目经理；项目经理在确定其确为风险后，定义风险发生机率和严重度并指定风险责任人，制订风险一旦发生的应急预案，并将其填写风险登记表上报项目管理办公室；项目管理办公室审核风险发生机率、严重度和风险责任人并负责风险状态的监控；风险责任人负责编制风险应对计划，并定期
30、报告风险状态；项目管理办公室负责发现跨项目的风险因素，并主持评估规避计划和应急预案；项目管理办公室将有关风险评估报告和规避计划、应急预案上报项目总监审批；所有发现的风险因素和审批通过的相应风险应对计划由项目管理办公室公布归档；在项目实施过程中由项目经理管理风险应对计划的执行，项目管理办公室通过项目周、月报跟踪监督。如下图示：1.1.3 项目实施计划1.1.3.1.1. 项目组织架构有效的组织结构，是项目成功的有力保证。对于一个银行服务总线项目，除了考虑项目的有效管理，也要考虑SOA类项目的实施特点；根据本次项目的范围和要求，项目的参考组织结构如下1.1.3.1.1.1 项目管理委员会项目管理委
31、员会负责监督并指导项目的实施进程，定期审核项目经理就项目进展执行情况的书面报告，对项目中存在的重大问题做出决策，协调解决重大问题和突发事件，决定对项目经理的任免。项目管理委员会由南京银行高层领导与本公司高层领导共同组成。1.1.3.1.1.2 服务总线管理组向项目管理委员会负责，在项目实施过程中进行服务标准和原则的控制，在未来项目实施完毕后，由这个组织管理和批准新的服务发布和渠道系统的接入。同时负责制定企业实施SOA项目的总体规划，从企业级的高度而非项目级参与项目管理。服务总线管理组由南京银行架构师和本公司企业架构师共同组成。项目实施完成后职责交给客户执行。1.1.3.1.1.3 项目管理组负
32、责向项目管理委员会定期报告项目进展情况，就项目中存在的问题提出解决建议，对项目进行有计划地组织管理，并检查项目进展情况。项目管理组由南京银行项目负责人和本公司项目经理和技术负责人共同组成。1.1.3.1.1.4 基础架构组负责基础架构的设计和流程建模设计。和企业架构师共同设计整体基础架构，完成本项目范围内的规划，考虑本项目与整个企业范围的IT架构的一致性规划。1.1.3.1.1.5 质量管理组直接隶属项目管理委员会，按制定的标准及控制手段执行进度管理，风险管理，全面的执行各项局方及业内规定的质量标准和工作流程。1.1.3.1.1.6 服务定义发布组负责在总线上发布服务和设定服务标准。根据基础架
33、构规划中的服务架构，对服务进行归类，根据服务定义模板，完成服务的识别、设定和在服务总线上的发布和配置。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.
34、3.1.4. 项目实施阶段划分根据我公司执行的ISO9001:2000质量管理体系的规定，将整个项目的实施过程划分为：需求分析、详细设计、系统开发、系统测试、试运行、系统验收六个过程；项目监控、管理的过程分为：配置管理、内部监理和项目变更管理三个过程。下面将针对以上六个实施过程和三个管理过程的实施计划即项目计划进行介绍。1.1.3.1.4.1 第一阶段：需求分析阶段自合同签定之日，与项目筹备小组并行完成业务需求分析，建立完善的项目组织机构，双方密切协作，各项目小组密切协作，各项工作同时有条不紊地展开。 完成并提交项目计划书，产品管理计划，质量控制计划； 详细的需求分析。需求分析的计划和方法主要
35、包括调研阶段划分、日程安排、调研形式和内容、调研过程和成果文档模板、资源安排、用户方要求等内容； 公司方与用户方进行应用软件需求的讨论、研究和分析，并一起根据需求调研分析报告和调研的各种成果编写软件需求规格说明书，对应用系统提出完整、准确、清晰、具体的要求，主要是需求框架和基本要素，并进行正式评审；时间跨度：6周需要资源（专职）：行方科技部2名、高伟达公司项目组需求分析人员3人。1.1.3.1.4.2 第二阶段：系统设计阶段 根据软件需求规格说明书，进行应用软件概要设计，设计系统整体结构、主要流程、相关模块接口以及数据库设计，定义详细设计和编码规范，整理概要设计说明书； 根据软件需求规格说明书
36、和概要设计说明书，由开发小组组长负责组织进行详细设计的分析讨论，完成交易的流程设计和报表设计等，整理详细设计说明书； 编写系统结构设计、功能设计、数据库结构及数据库设计、系统内外接口及界面设计、系统出错处理及安全保障设计、代码数据设计、联机交易流程以及批处理交易流程等设计文档； 启动数据转换工作，定义统一的中间格式。时间跨度：6周需要资源（专职）：行方科技部2名、高伟达公司现场8名技术、业务骨干，产品咨询1名。1.1.3.1.4.3 第三阶段：系统开发阶段与系统设计阶段对应，是系统开发阶段，企业服务总线建设是基于ORACLE成熟总线产品OSB，因此在进行了周密严格的需求分析及详细设计的前提下，
37、真正需要的开发工作并不多，周期相应较短。 在系统设计完成后，由公司项目实施团队开发人员根据各种设计文档进行应用软件的编码工作； 系统开发工作完成及培训准备工作完成后，即开始进入全面培训阶段； 系统开发工作完成后，进行应用软件单元测试和系统集成测试；时间跨度：2周需要资源：行方科技部1名、高伟达公司现场设计开发人员、测试人员10名。1.1.3.1.4.4 第四阶段：系统测试阶段系统开发完成后进行系统的测试工作。本阶段主要指在南京银行建立的测试环境中，进行全面的模拟测试，完成系统功能测试，由于测试的重要性，预计将花费两个月左右的时间来完成对系统的模拟测试。 测试对象是编程结束时提交内容； 制定测试
38、计划和选定测试方法、准备测试数据、确认测试环境（应该是硬件系统通过初步验收后所构成的标准模式运行环境）； 进行测试记录； 解决测试发现的问题，分析测试结果，形成测试报告； 为测试后的确认和初步验收做好准备。 验收测试：在系统试运行一段时间后，由验收小组组织进行全面系统验收测试，以证明系统的合格性。系统的验收工作，系统验收详见验收和测试相关章节。时间跨度：8周需要资源：行方科技部3名、接入系统相关人员1名、高伟达公司现场8名技术、业务骨干。1.1.3.1.4.5 第五阶段：试运行阶段模拟测试完成，进入系统试运行阶段。考虑到试运行期间的目的，是将经过集成测试及性能测试后较为稳定的版本投入到实际工作
39、环境中运行，用于检验系统是否完全满足实际业务的需要，为新系统的上线运行做准备。 系统上机联调； 试运行期间，核查新系统是否满足实际业务需求； 试运行期间发现的问题，进行记录、调整、解决； 试运行期间还是测试的良好时机，在该阶段，应对各网点的设备、网络状况、业务响应时间等内容进行测试。时间跨度：4周需要资源：行方科技部1名、接入系统相关人员1名、高伟达公司现场4名技术、业务骨干。1.1.3.1.4.6 第六阶段：上线验收及维护阶段上线验收阶段的主要工作是制定详细的上线计划，确认上线步骤。选择适宜日期开始上线实施工作，做好外连系统和外围系统的预前通知和公告工作。时间跨度：24周需要资源：行方相关人
40、员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 并行管理阶段三：项目变更工作涵盖软件实施项目实
41、施过程中顾客需求变更及阶段性成果变更的处理。包括需求分析、详细设计、系统开发、系统测试、系统维护、系统交付、系统验收各阶段的变更以及涉及项目管理的变更。1.1.3.1.5. 项目实施周期计划整个项目实施周期计划如下：项目阶段起始时间结束时间需求分析阶段产品培训TT+5需求梳理T+6T+13需求分析T+14T+28需求评审T+29T+30系统设计阶段概要设计T+31T+43详细设计T+44T+57设计评审T+58T+60系统开发阶段应用开发T+61T+70单元测试T+71T+80集成测试、用户验收测试环境准备T+71T+80系统测试阶段集成测试T+81T+90用户验收测试T+91T+100性能测
42、试T+101T+120系统试运行上线系统培训T+121T+125系统运行环境准备T+126T+130上线T+131T+133系统试运行试运行总结T+134T+150项目验收1.1.4 项目测试方案1.1.4.1 测试目的对系统进行集成测试。对测试范围内需要测试的特性进行“完整性”、“准确性”、“有效性”、“可靠性”、“稳定性”验证并对性能指标进行测评。通过本次测试，达到以下具体目的：1) 保证软件基本功能使用正常，严重缺陷率小于5%；2) 保证系统可靠稳定运行；3) 保证项目相关文档符合CMMI 3级文档规范。1.1.4.2 测试对象1. 系统具有总线基本功能如：协议转换、交易路由、数据转换；
43、2. 服务封装规范满足行内存量、增量业务系统；3. 对各类系统提供的适配器功能满足性；4. 系统并发处理能力及响应时间满足要求；5. 系统可靠性、稳定性。1.1.4.3 测试范围测试范围最终以实际形成的系统业务需求说明书的内容为准。1.1.4.4 测试方法1.1.4.4.1. 功能测试配合开发组的开发过程分阶段提供测试小结,测试方法以标准黑盒技术为主。本次测试过程中，功能测试的执行环节分为两个阶段，具体描述如下：阶段名称具体方法目标阶段一1. 执行测试用例中的“基本场景”用例，验证系统基本功能的使用正常；2. 保证系统执行正常操作时，数据的输入输出流转正常（使用正常、有效的数据）。保障软件正操
44、操作时功能正常阶段二执行测试用例中的“异常场景”用例。保证系统异常操作时，系统的健壮性有一定保障，（使用异常数据）。回归测试1. 对“阶段一”、“阶段二”发现并被修正的缺陷进行再次测试；2. 抽样执行测试用例中的“异常场景”用例。保障软件的缺陷遗留率小于5%1.1.4.4.2. 性能测试分为负载测试、压力测试、稳定性测试等三个阶段。使用LoadRunner进行测试。根据性能测试调研得到的数据构建业务模型，进而构建测试模型。测试模型包含多种子类型，不同类型的测试模型应用于不同类型的性能测试。性能测试模型包含要素如下：测试模型子类型所含业务并发用户数思考时间单业务压力测试模型1单业务压力测试模型2
45、混合业务压力测试模型压力测试模型稳定性测试模型本次测试包含的性能测试类型如下：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. 接收测试用例由“基本测试场景”中选取出代表性用例，用于验证开发团队提交测试版