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

1、IT工程实施与管理方案-投标书 1.1 工程实施与管理 1.1.1 工程实施方法论 针对南京银行企业效劳总线系统工程，高伟达公司基于对客户需求、业务目标、业务能力和IT环境的理解，结合多年的软件开发和系统实施经验，将工程的实施周期划分为六个活动阶段，保证在工程生命周期内，应用合理的工程管理和控制技术。通过专注于使客户投资回报最大化，和使客户的投资风险最小化的关键战略和战术领域，加快工程实施速度，使得工程成功地完成。这些阶段的特性是可循环往复性，使客户可以尽快地获得新的应用系统所带来的好处。 工程定义阶段 在这个阶段, 所有与分期实施相关的工程活动都被明确定义, 工程的"工程利益相关者

2、"被指定，工程经理和客户工程经理的角色和职责被传达给所有的"工程利益相关者"。管理工程所需的工程控制结构被定义,所有需要的工程规划文件被创立, 客户的业务问题和被用来衡量工程成功的衡量标准被确认。 制定解决方案范围，在一个高级别上定义哪些模块将被实施，估算预期需要的客户化程度, 以及勾画出在产品之外需要开发的内容和要提交的技术成果。解决方案范围文档包括解决方案范围概述, 功能范围, 流程范围, 客户化问题, 其他风险, 外部依赖条件以及假设。这个工作为未来工程决策, 统一或达成"工程利益相关者"之间就有关工程参数的共识，提供书面的文档。它阐述以

3、SOW为根底的业务需求，并且把它转化成产品 模块实施信息。 简而言之, 这个阶段组建工程团队，保证客户实施工程的成功。公司人员与客户人员一道，组建工程团队, 设定工程方法和范围，并建立工程管理控制。主要交付的成果有，解决方案范围和工程管理控制。制定了工程质量检查方案。 1.1.1.2 需求分析阶段 在需求调研阶段, 在工程管理小组的指导下, 由公司和客户组成的统一的工程团队将识别并且书面记录在开始设计客户解决方案之前所必须弄清楚的，需处理的问题。工程团队书写、提炼满足客户业务目标所需的功能和技术要求。主要交付的技术成果为业务需求和差距分析。 专家效劳参谋将进行一个配臵检查，以保证系统有精确的规

4、格，便于购置硬件和架构部署。在有技术客户经理参与的情况下, 通过完成初始的评估, 来建立部署的基准，及通过给战略，管制，用户采用, 流程和技术各方面打分的评估来建立业务目标。 1.1.1.3 工程设计阶段 在设计阶段, 主要的目标是设计一个能够最正确地满足客户明确的业务需求的解决方案，并且为培训和系统测试做准备。 在设计(Design)阶段,工程团队利用应用系统屏幕流程和设计布局来映射在发现阶段确定的需求,设计解决方案的原型。 主要交付的技术成果是解决方案设计文档和测试策略。这个策略定义测试方案和测试要求，以保证一个系统部署的成功。主要的目的是提供一个高级的测试策略，以便使用自动化的测试工具和

5、/或手工过程来实现功能测试,系统整合测试(SIT),用户验收测试 (UAT)和性能测试。 专家效劳参谋要执行设计检查，来评估由客户或集成商提供的书面设计文档，并且提供详细的建议清单。设计标准包括,但不限于，应用系统性能,对升级的影响,应用系统维护, 与数据模型相关的问题和常规的最正确做法。 1.1.1.4 工程开发阶段 在开发阶段，工程团队将开发应用系统, 提供任何需要的扩展功能和外部接口, 为客户部门部署和持续支持解决方案做准备。工程团队配臵应用系统、所有需要的扩展功能和外部接口。主要交付的技术成果有功能测试和系统测试。这些流程整合和测试活动更好地保证介入的系统功能与客户组织的业务需求协调一

6、 致。 专家效劳参谋应该进行一个配臵检查，来评估所有经过客户化改造的实施文档。在这个检查过程中,所有这样的文件都将被评估，以使应用系统性能, 应用系统升级,系统维护工作量和常规最正确实践最优。 1.1.1.5 工程验证阶段 在验证阶段, 将完成新系统全部功能的测试。这个阶段分两个局部。第一局部,工程团队进行一个对有生产数据的应用系统的全部功能进行测试。在这个检测完成后,关键用户然后进行一个代表性的验收测试，以保证系统正确地处理用户的需求。一旦全面的功能测试结束, 将进行一个使用系统工具的，严格的性能测试。这一阶段主要交付的技术成果为用户验收测试和性能测试结果, 包括性能,容量和寿命测试。 适时

7、的性能调整审计，可保证整个企业架构环境的性能最正确。在这个检查中, 专家效劳将主动性地识别任何性能问题, 这样将减少在运行时出现问题的风险，增加系统生产切换的信心。在有技术客户经理参与的情况下, 可执行一个实施准备就绪检查，以确认系统是否可以部署了。这个实施准备就绪检查是用来评估实施风险,技术上是否准备停当以及部署策略。 此时，应该召开管理人员定向协调研讨会，将责任转移给一线的员工，这些员工将开始支持业务流程和技术的推出。在管理人员定向协调研讨会上, 工程团队与客户的管理团队一起工作，以获得维持资助人的内部负责，并把正确的信号传达给组织的其他成员。 1.1.1.6 部署上线阶段 部署上线阶段内

8、的第一个活动是实施一个投产导航。这个导航是被用来测试全面的生产部署, 并且在客户业务环境中的一局部部门中进行的，例如一个地区或一个区域。生产导航在机构的业务环境中局部部门里，为用户提供所有系统的特点。来自于生产导航的反响信息指导整个的部署。 同样在这个过程中, 专家效劳参谋应该进行生产准备就绪检查, 通过主动地识别任何可能造成部署中断和使实施的系统解决方案的技术优点打折扣的所 有问题，来协助系统的顺利推出。 此时, 要召开流程实施研讨会，部署流程最优实践，来优化人, 流程和技术的配合。目的是在客户所有的一线机构中，使用变革和销售流程的最正确实践，使最初的赞助人和行政领导团队完全满意。 1.1.

9、2 工程管理方案 1.1.2.1 工程管理概述 工程管理包括在工程生命周期中协调所有工程管理知识领域所涉及的过程。它确保工程所有的组成要素在正确的时间结合在一起，以成功的完成工程。进行工程整体管理时，必定涉及工程的范围、质量、时间和本钱管理以及人力资源、沟通、风险管理等各个环节，工程管理一个复杂的工程，在此主要针对南京银行企业效劳总线工程的工程进度管理、变更管理、沟通管理、质量管理、风险管理等相关策略进行描述。 1.1.2.2 工程进度管理 通过工程进度的管理最终明确工程开发阶段的进度控制活动和关键流程。 ? 工程经理： ? 根据软件开发方案编制详细的阶段开发方案以及每项任务的边界时 间，并召

10、集过程控制人员、专题小组负责人审核该方案； ? 审核各专题小组拟订的每项任务的日程安排； ? 检查和控制工程进度； ? 制定进度变更方案； ? 过程控制人员： ? 协助审核详细的阶段开发方案和任务边界时间； ? 监督工程进展； ? 专题小组负责人： ? 协助审核详细的阶段开发方案和任务边界时间； ? 在听取小组成员意见的根底上，拟订每一项任务的日程安排； ? 负责检查和控制任务的进度，并填写进度控制表； ? 负责制订任务变更方案。 1.1.2.2.1. 进度安排流程 ? 工程经理根据工程方案，明确该阶段的边界时间； ? 根据工程方案中的任务PERT网络图，找出该阶段的关键任务并进一步分 解、细

11、化，在此根底上绘制更具体的阶段任务PERT网络图； ? 拟订详细的阶段方案； ? 确定每一关键任务的边界时间； ? 召集各专题小组负责人审核拟订的方案，并修改； ? 专题小组负责人确定任务的日程安排；对于大型的或时间要求严格的项 目，进度安排应以天为单位； ? 征求小组成员的意见； ? 交由工程经理和过程管理人员审核。 1.1.2.2.2. 进度控制流程 ? 工程经理和过程管理人员按照阶段PERT图，标志阶段中被跟踪的关键任 务和里程碑，并将之告知专题小组负责人； ? 专题小组负责人按照任务的日程安排，确定任务完成期间的关键时间点， 并将之告知专题小组成员； ? 专题小组负责人经常与成员沟通，

12、了解任务进展；并定期检查，填写任 务进度表和下期方案表，及时发现问题； ? 工程经理定期组织专题小组负责人，召开工程状态会议，了解任务进展， 及时发现问题；工程过程管理人员参加会议或了解会议的记录； ? 专题小组负责人在执行中发现延迟，分析原因： ? 人员紧张：组内调配不了的，找工程经理解决； ? 事先预估缺乏：调整任务日程安排；假设解决不了，告知工程经理， 会同过程管理人员，调整详细的阶段方案；如果阶段内消化不了的 问题，那么工程经理按照?配臵管理的程序?，变更软件开发方案。 1.1.2.3 工程变更管理 针对工程变更管理组织变更控制小组，由工程组经理、工程管理部人员、工程总监、客户、客户部

13、成员组成，考虑并授权工程的重大修改修改工作量超过一周的。而工程经理负责工程的一般修改决策修改工作量在一天以上，一周以内。 变更管理活动包括修改请求、评估、通过、执行和跟踪。 变更管理要点如下： ? 变更批准权限： ? 变更控制组负责讨论和决策工程的重大修改； ? 工程经理讨论和决策一般性修改；并报工程管理部备案； ? 修改审批程序： ? 根据不同地点的客户有不同的审批程序。 1.1.2.3.1. 变更状态登记 变更状态登记活动记录和报告各种配臵项的状态，记录在工程生命周期中的任何管理信息和历史信息。包括：所有变更请求表、所有变更报告单、所有变更记录。由工程管理人员存取状态登记。 变更状态登记的

14、目的是为了控制软件需求发生变更时的处理过程，使之按照制定的规程进行，以保证软件需求的一致性。 1.1.2.3.2. 变更管理流程 ? 客户方或高伟达提出变更请求，填写变更申请表； ? 将变更申请表交本工程组的工程经理； ? 双方工程经理或工程经理授权人，必须以书面形式确认共同审阅， 评估该需求变更的技术有效性和对本工程的影响； ? 如果审阅批准该请求，那么双方工程经理或工程经理授权人，必须以书 面形式确认签字确认，变更申请表将被贵行文档管理员登记后，转发给高伟达。如果未获批准，其原因将反响给该需求变更发起人； ? 高伟达在收到经审阅批准的需求变更申请后的三个工作日内，发给贵行 一份书面确认书，

15、确认其收到，并给出分析与执行变更所需时间和工作量的估算； ? 根据请求的变更程度和复杂度，高伟达进一步进行本钱评估，假设不需成 本，那么直接执行变更工作；假设需要增加本钱，那么以书面形式通知贵行文档管理员，贵行管理员登记后，按照工程管理方法中的工程变更管理流程处理。 1.1.2.4 工程沟通管理 南京银行ESB工程是一个技术与业务互动的工程，工程的成功很大程度上依赖于业务人员的参与程度及技术人员对业务需求的透彻分析，这就要求技术与业务人员保证充分的交流，制定并遵守工程内部的沟通管理方案。 1.1.2.4.1. 工程沟通形式 根据本工程的组织形式及特点，我们建议采取如下多种方式的沟通形式： 1.

16、1.2.4.2. 会议管理制度 工程开始进行以后，要有效地控制工程，需要在各个关键时刻召开关键会议。 关键会议的主要内容是总结上一阶段的工作，分析问题、提出建议，并介绍下一 阶段的主要任务和目标，使各有关人员都能做到心中有数，明确努力的方向。关 键会议也是协调各不同小组之间的人员以及工作任务的重要手段。 除关键会议外，在工程进行的全过程中，应定期召开例会，会上主要介绍项 目进展情况，检查进度、是否存在问题等，会议时须做详细的会议记录并在会后 报送所有工程相关人员。主要的工程会议流程规定如下： ? 会前准备： ? 做好准备工作，如明确会议目的和会议议程等； ? 把会议中要求讨论的材料事先下发给开

17、会成员； ? 提前两天通知各位与会成员； ? 准备会议环境、会议用设备等； ? 会议之中： ? 会议成员准时到会； ? 按会议议程逐项进行； ? 严格控制会议时间； ? 会后跟踪： ? 会议决议落实和检查。 1.1.2.5 工程质量管理 为保证工程顺利实施及系统质量，必须在工程管理过程和工程实施过程上加大质量管理力度。通过高伟达公司实施的成功案例，我们深深体会到“质量是方案出来的这一现代质量学观点所蕴含的深刻道理，所以，我们在工程启动及工程进展的各个阶段都会仔细制定各项工作方案，严格按照审核通过的方案进行工程控制。 针对本工程，我们建议从QA及QC两方面保障工程的顺利实施，具体的质量保障措施如

18、下： 1.1.2.5.1. 质量保证 本工程将设臵质量保证小组，由南京银行和高伟达公司各出一名人员担任QA的角色，其工作任务是根据工程总体组制定的质量核对单，在工程进展过程按照质量核对单逐项审核工程是否按照方案约定执行和控制，并直接向南京银行的相关领导汇报工程实施的质量状况。 1.1.2.5.2. 正式评审 根据本工程的特点，本工程中将对工程方案、软件需求规格说明书、系统设计说明书、测试规格说明书、测试报告等文档，组织南京银行相关领导、专家进行正式评审，以便审核系统开发中各阶段所产生的过程文档，以保证文档内容与上一阶段所产生的软件文档内容一致，并且符合使用者的需求。 1.1.2.5.3. 交叉

19、审查 除工程要求的正式评审内容外，本工程还将对各模块软件代码实行交叉评审制度。各模块负责人应根据总体组制定的代码质量审核清单，对所负责检查的其他模块软件代码进行仔细审查，对代码质量不能通过交叉评审的那么必须进行返工。整体的软件代码交叉评审总量不能少于60。 1.1.2.5.4. 变更控制 为保证软件产品质量，开发过程将严格采用配臵管理工具进行变更控制，其目的是保证最终软件产品能够符合业务需求的各项要求，并对开发过程进行监控、报告和提供咨询支持，它包括下面的质量属性要求： ? 软件产品与需求、说明书和设计一致； ? 按照说明的标准建立文档； ? 可测试和可维护； ? 被识别、管理、评审和测试；

20、? 当变更发生时可管理。 1.1.2.6 工程风险管理 任何工程开发实施过程中都会遇到各种风险，在各方面都会遇到不同规模的风险，因此需要了解工程本身的风险、技术 风险、新产品的风险、工程资源风险、工程过程风险等全方位的风险因素。通过对风险的量化提供一个方案来管理预防风险，同时对于潜在的风险也应该建立意外事件的应急方案，使其在必要时能够以可控的及有效的方式作出反响。 ? 针对需求风险，南京银行应把握系统建设起点要高、标准运作为系统建设的 根底工程、采用构件化技术进行应哟软件开发、采用B/S技术降低信息点维护本钱的方式躲避需求风险。 ? 针对合作风险，选择一个长久的、上规模、具备成熟行业经验、工程

21、管理规 范、技术先进、员工有归属感、真正站在用户的立场上考虑问题的公司作为后盾，高伟达集团是能为您最大限度地控制合作风险。 ? 针对资源风险，拥有健全的组织与管理，在防止人员流动的根底上，即使因 个人原因必须离职时，高伟达公司也因其标准的、体系化的管理与产品架构而使工程根本不受影响或极少受到影响。 ? 针对技术风险，高伟达的银行业务系统拥有多个成功实践经验，具备与国外 接轨的理念与技术，同时拥有不断调整、更新的技术体系、以及参照标准体系指定标准质量标准并在实施过程中加强阶段评审，使因为技术原因而可能 导致的风险降低到最小。 除此之外，为预防操作风险，在南京银行自身加强制度管理的根底上，高伟达还

22、提供培训考试合格上岗及定期培训定期总结分析的模式来躲避此类风险。 1.1.2.6.1. 风险管理内容 风险管理的内容如下： ? 工程实施前和实施中对风险的发现、识别、上报、分析及风险责任人的 指定； ? 风险应对方案的制订和执行应对方案包括两局部，一是在如何降低风 险发生机率的躲避方案；一是当风险不幸变成现实时，如何应对的应急预案； ? 风险状态的监控和更新； ? 定期对工程风险进行统计、分类和总体结构分析。 1.1.2.6.2. 风险管理中的相关角色和责任 1.1.2.6.3. 风险严重程度 ? 灾难的：会因为无法满足需求而导致任务失败，会产生错误导致进度延 迟和预算严重超支； ? 严重的：

23、会因为无法满足需求而导致系统性能下降，使得工程能否成功 受到臵疑，严重影响工程里程碑的范围、交付日期和交付质量以及会影响其它工程进展的风险； ? 轻微的：会因为无法满足要求而导致次要任务的退化，影响工程里程碑 的范围、交付日期和交付质量以及会影响其它工程进展的但不严重的风险； ? 可忽略的：不影响或轻微影响工程里程碑的范围、交付日期和交付质量 的风险，只是无法满足要求而导致使用不方便或不易操作。 1.1.2.6.4. 风险状态 ? 已提交：风险识别人已填写风险登记表，完成了风险号分配、风险描述 并有工程经理提交； ? 拒绝：工程管理办公室认为风险导入人所提出的风险不属于工程风险； ? 已完成方

24、案：风险责任人得到风险登记表后，对其进行分析并完成应对 方案； ? 躲避方案：风险责任人正在根据应对方案躲避风险； ? 风险已躲避：风险责任人已成功躲避风险并得到工程管理办公室认可； ? 发生进入应急方案：风险责任人未成功躲避风险，风险发生，执行应急 预案。 1.1.2.6.5. 风险分类 本工程中，风险主要分为以下几类： ? 管理类风险 工程管理没有遵循工程管理的制度、时间、岗位的要求。出现工程的风险。 ? 资源类风险 由于人力资源、设备环境等原因产生。例如，ATM设备没有驱动程序，无法进行程序调试。 ? 业务类风险 业务风险主要表现在业务需求不清晰，变动频繁。 ? 技术类风险 技术风险主要

25、表达在技术架构不合理，各个子系统、效劳渠道无法进行整合。 1.1.2.6.6. 风险管理流程 风险管理流程包括： ? 工程启动前风险识别与防范流程 在各工程启动前，应当由工程管理办公室指导各个工程提交其工程风险因素识别、评估和应对措施方案； 工程管理办公室根据各工程的风险识别方案，以及其对工程风险的理解，完成工程风险因素识别、评估和躲避的工程风险躲避方案以及制订工程风险应急预案； 工程管理办公室将有关风险应对方案上报工程总监审批； 将工程总监审批过的风险应对方案提交给领导领导组审批； 审批通过的风险应对方案由工程管理办公室公布归档； 在工程实施过程中由工程经理管理风险应对方案的执行，工程管理办

26、公室通过工程周、月报跟踪监督。 如以下图示： ? 工程运行中风险管理流程 在工程实施过程中，所有工程组成员均有责任报告进程中发现的风险因素，并报告工程经理； 工程经理在确定其确为风险后，定义风险发生机率和严重度并指定风险责任人，制订风险一旦发生的应急预案，并将其填写风险登记表上报工程管理办公室； 工程管理办公室审核风险发生机率、严重度和风险责任人并负责风险状态的监控； 风险责任人负责编制风险应对方案，并定期报告风险状态； 工程管理办公室负责发现跨工程的风险因素，并主持评估躲避方案和应急预案； 工程管理办公室将有关风险评估报告和躲避方案、应急预案上报工程总监审批； 所有发现的风险因素和审批通过的

27、相应风险应对方案由工程管理办公室公布归档； 在工程实施过程中由工程经理管理风险应对方案的执行，工程管理办公室通过工程周、月报跟踪监督。 如以下图示： 1.1.3 工程实施方案 1.1.3.1.1. 工程组织架构 有效的组织结构，是工程成功的有力保证。对于一个银行效劳总线工程，除了考虑工程的有效管理，也要考虑SOA类工程的实施特点；根据本次工程 的范围和要求，工程的参考组织结构如下 1.1.3.1.1.1 工程管理委员会 工程管理委员会负责监督并指导工程的实施进程，定期审核工程经理就工程进展执行情况的书面报告，对工程中存在的重大问题做出决策，协调解决重大问题和突发事件，决定对工程经理的任免。工程

28、管理委员会由南京银行高层领导与本公司高层领导共同组成。 1.1.3.1.1.2 效劳总线管理组 向工程管理委员会负责，在工程实施过程中进行效劳标准和原那么的控制，在未来工程实施完毕后，由这个组织管理和批准新的效劳发布和渠道系统的接入。同时负责制定企业实施SOA工程的总体规划，从企业级的高度而非工程级参与工程管理。效劳总线管理组由南京银行架构师和本公司企业架构师共同组成。工程实施完成后职责交给客户执行。 1.1.3.1.1.3 工程管理组 负责向工程管理委员会定期报告工程进展情况，就工程中存在的问题提出解决建议，对工程进行有方案地组织管理，并检查工程进展情况。工程管理组由南京银行工程负责人和本公

29、司工程经理和技术负责人共同组成。 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 根底组件开发组

30、负责根底的，公共的组件的统一开发；开发从日志，平安到各种便利工具的公共组件，完成在OSB之上的各种组件的扩展工作，如扩展函数，扩展报文转换方法，扩展监控处理模块，进行监控平台的集成等。 1.1.3.1.1.8 测试组 负责系统的联合测试工作，在工程质量方针指导下，进行测试管理，制定设计系统测试方案、测试方案、测试案例、各项测试、形成测试报告并对测试结果进行跟踪，包括不同阶段的测试工作。 1.1.3.1.2. 实施人员名单 1.1.3.1.3. 实施人员简历 1.1.3.1.4. 工程实施阶段划分 根据我公司执行的ISO9001:2000质量管理体系的规定，将整个工程的实施过程划分为：需求分析、

31、详细设计、系统开发、系统测试、试运行、系统验收六个过程；工程监控、管理的过程分为：配臵管理、内部监理和工程变更管理三个过程。下面将针对以上六个实施过程和三个管理过程的实施方案即工程方案进行 介绍。 1.1.3.1.4.1 第一阶段：需求分析阶段 自合同签定之日，与工程筹备小组并行完成业务需求分析，建立完善的工程组织机构，双方密切协作，各工程小组密切协作，各项工作同时有条不紊地展开。 ? 完成并提交工程方案书，产品管理方案，质量控制方案； ? 详细的需求分析。需求分析的方案和方法主要包括调研阶段划分、日程 安排、调研形式和内容、调研过程和成果文档模板、资源安排、用户方 要求等内容； ? 公司方与

32、用户方进行应用软件需求的讨论、研究和分析，并一起根据需 求调研分析报告和调研的各种成果编写?软件需求规格说明书?，对应用 系统提出完整、准确、清晰、具体的要求，主要是需求框架和根本要素， 并进行正式评审； 时间跨度：6周 需要资源专职：行方科技部2名、高伟达公司工程组需求分析人员3人。 1.1.3.1.4.2 第二阶段：系统设计阶段 ? 根据?软件需求规格说明书?，进行应用软件概要设计，设计系统整体结 构、主要流程、相关模块接口以及数据库设计，定义详细设计和编码规 范，整理?概要设计说明书?； ? 根据?软件需求规格说明书?和?概要设计说明书?，由开发小组组长负 责组织进行详细设计的分析讨论，

33、完成交易的流程设计和报表设计等， 整理?详细设计说明书?； ? 编写系统结构设计、功能设计、数据库结构及数据库设计、系统内外接 口及界面设计、系统出错处理及平安保障设计、代码数据设计、联机交 易流程以及批处理交易流程等设计文档； ? 启动数据转换工作，定义统一的中间格式。 时间跨度：6周 需要资源专职：行方科技部2名、高伟达公司现场8名技术、业务骨干，产品咨询1名。 1.1.3.1.4.3 第三阶段：系统开发阶段 与系统设计阶段对应，是系统开发阶段，企业效劳总线建设是基于ORACLE成熟总线产品OSB，因此在进行了周密严格的需求分析及详细设计的前提下，真正需要的开发工作并不多，周期相应较短。

34、? 在系统设计完成后，由公司工程实施团队开发人员根据各种设计文档进 行应用软件的编码工作； ? 系统开发工作完成及培训准备工作完成后，即开始进入全面培训阶段； ? 系统开发工作完成后，进行应用软件单元测试和系统集成测试； 时间跨度：2周 需要资源：行方科技部1名、高伟达公司现场设计开发人员、测试人员10名。 1.1.3.1.4.4 第四阶段：系统测试阶段 系统开发完成后进行系统的测试工作。本阶段主要指在南京银行建立的测试环境中，进行全面的模拟测试，完成系统功能测试，由于测试的重要性，预计将花费两个月左右的时间来完成对系统的模拟测试。 ? 测试对象是编程结束时提交内容； ? 制定测试方案和选定测

35、试方法、准备测试数据、确认测试环境应该是 硬件系统通过初步验收后所构成的标准模式运行环境； ? 进行测试记录； ? 解决测试发现的问题，分析测试结果，形成测试报告； ? 为测试后确实认和初步验收做好准备。 ? 验收测试：在系统试运行一段时间后，由验收小组组织进行全面系统验 收测试，以证明系统的合格性。系统的验收工作，系统验收详见?验收和测试?相关章节。 时间跨度：8周 需要资源：行方科技部3名、接入系统相关人员1名、高伟达公司现场8名技术、业务骨干。 1.1.3.1.4.5 第五阶段：试运行阶段 模拟测试完成，进入系统试运行阶段。考虑到试运行期间的目的，是将经过集成测试及性能测试后较为稳定的版

36、本投入到实际工作环境中运行，用于检验系统是否完全满足实际业务的需要，为新系统的上线运行做准备。 ? 系统上机联调； ? 试运行期间，核查新系统是否满足实际业务需求； ? 试运行期间发现的问题，进行记录、调整、解决； ? 试运行期间还是测试的良好时机，在该阶段，应对各网点的设备、网络 状况、业务响应时间等内容进行测试。 时间跨度：4周 需要资源：行方科技部1名、接入系统相关人员1名、高伟达公司现场4名技术、业务骨干。 1.1.3.1.4.6 第六阶段：上线验收及维护阶段 上线验收阶段的主要工作是制定详细的上线方案，确认上线步骤。选择适宜日期开始上线实施工作，做好外连系统和外围系统的预前通知和公告

37、工作。 时间跨度：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

38、.1.4.9 并行管理阶段三：工程变更工作 涵盖软件实施工程实施过程中顾客需求变更及阶段性成果变更的处理。包括需求分析、详细设计、系统开发、系统测试、系统维护、系统交付、系统验收各阶段的变更以及涉及工程管理的变更。 1.1.3.1.5. 工程实施周期方案 整个工程实施周期方案如下： 1.1.4 工程测试方案 1.1.4.1 测试目的 对系统进行集成测试。对测试范围内需要测试的特性进行“完整性、“准确性、“有效性、“可靠性、“稳定性验证并对性能指标进行测评。 通过本次测试，到达以下具体目的： 1) 保证软件根本功能使用正常，严重缺陷率小于5%； 2) 保证系统可靠稳定运行； 3) 保证工程相关文

39、档符合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.1.4.4.2. 性能测试 分为负载

40、测试、压力测试、稳定性测试等三个阶段。使用LoadRunner进行测试。根据性能测试调研得到的数据构建业务模型，进而构建测试模型。测试模型包含多种子类型，不同类型的测试模型应用于不同类型的性能测试。 性能测试模型包含要素如下： 本次测试包含的性能测试类型如下： 1) 压力测试 基于本次的测试的目的和需要测试的特性，将本次测试分为两个阶段：阶段一，单业务压力测试；阶段二，多业务混合压力测试。 a) 单业务压力测试 测试目的： 排查各个典型业务的压力瓶颈。 选用测试模型 单业务压力测试模型。 b) 混合业务压力测试 测试目的： 在排查各个典型业务的性能瓶颈后，测试该系统的最大并发用户数， 并找到系

41、统存在的性能瓶颈。 选用测试模型： 混合业务压力测试模型。 2) 稳定性测试 测试目的： 检查系统在连续运行240小时过程中的性能表现 选用测试模型： 稳定性测试模型。 1.1.4.4.3. 文档测试 对需求说明书、设计文档进行标准性检查。 1.1.4.5 测试用例 本次测试中将主要的测试用例归类为不同的测试场景，同时设计易用性测试用例和接收测试用例。 1.1.4.5.1. 根本测试场景 描述系统正常操作流程，以通过操作完整实现一个业务功能为原那么。其中每一个步骤对应一个测试用例。测试用例中采取的数据都为正常数据。 1.1.4.5.2. 异常测试场景 基于系统正常操作流程，在整实现一个业务功能

42、的操作过程中验证系统的数据校验、特殊操作处理等功能。其中每一个步骤对应一个测试用例。测试用例中采取的数据有正常数据和异常数据。 1.1.4.5.3. 接收测试用例 由“根本测试场景中选取出代表性用例，用于验证开发团队提交测试版本的可测性。 1.1.4.6 人员及职责 1.1.4.7 测试工作输出 1.1.4.8 启动、暂停/重启、结束准那么 1.1.4.8.1. 启动准那么 待测试系统部署完毕，功能使用正常。 1.1.4.8.2. 暂停/再启动准那么 ? 测试版本未通过“接收测试，需要由开发人员修正后再次接收测试； ? 测试过程中发现性能瓶颈时测试执行暂停，由开发人员进行调优； ? 开发人员经

43、过调优后解决系统测试瓶颈后，可以再次启动 1.1.4.8.3. 退出准那么 通过压力测试发现的性能瓶颈经过待测试系统开发人员对系统调优后无解决时。 1.1.4.9 测试风险分析 1.1.5 工程上线管理 在系统上线过程中，首先成立上线领导小组，在领导小组的组织下，编写上线方案和应急预案，将上线方案和应急预案提交工程管理办公室进行评审，待评审通过后进行实施。 1.1.6 验收管理 为加强南京银行企业效劳总线系统验收管理工作，确保工程建设到达合同要求，高伟达公司建立该验收管理方法，与南京银行一道保障工程的顺利成功实施。 1.1.6.1 工程验收的过程 工程验收包括阶段验收和最终验收以下简称“终验两

44、局部。工程只有阶段验收合格后才能投入试运行，终验合格后才能移交并投入正式运行。 1.1.6.2 工程验收的参与者 阶段验收工作由南京银行和高伟达公司共同组织实施，终验工作在高伟达公司申请后由南京银行负责组织实施。 1.1.6.3 验收测试的范围 验收测试的范围包括招标文件中的所有南京银行企业效劳总线工程内容。 1.1.6.4 验收测试的责任 高伟达公司负责建立验收测试环境，详细设计所有的验收测试方案。测试由高伟达公司进行准备，由南京银行组织验收，测试验收方式和机构由南京银行确定，全部费用由高伟达公司承当。 南京银行负责组织对验收测试结果进行评估。在出现严重缺陷时，南京银行可以决定将所有的测试暂

45、停，直至缺陷得到纠正。 1.1.6.5 验收测试地点 南京银行 1.1.6.6 验收测试的标准 高伟达公司为每一项的测试编写验收测试手册。验收测试手册的内容包括： ? 验收测试目的 ? 验收测试环境设备 ? 验收测试过程的描述 ? 验收测试结果及分析 1.1.6.7 验收方法及标准 对工程进行阶段验收或终验时，需按如下步骤验收： 一登记造册。对工程中所涉及的所有硬件、软件及工程文档逐一登记造册。 二对照检查。对照检查工程各项建设内容是否与合同条款及系统需求规格相一致。 三操作检查。 1、操作硬件设备，验证是否与硬件提供的技术性能相一致； 2、运行软件系统，操作处理业务，检查是否与合同规定的功能

46、一致； 3、对工程文档进行包括内容针对性、内容充分性、内容一致性、文字明确性、图表详实性等方面检查。 4、工程的验收以国家标准、行业标准或国际惯例等为标准。 1.1.6.8 阶段验收内容及程序 1.1.6.8.1. 阶段验收目的 检查整个工程的设备、系统功能、工程文档等，使其到达合同建设要求。 1.1.6.8.2. 检验条件 承建单位申请工程阶段验收，应当符合以下条件： 一 所有建设内容按照合同要求全部建成，并满足使用要求； 二 各个分项工程全部阶段验收合格； 三 验收审核材料齐全，材料主要包含以下几个局部： 1、 根底资料：招标书、投标书、合同书、批复文件、系统设计说明书、系统功能说明书、系

47、统结构图、工程详细实施方案； 2、 工程竣工资料：工程开工报告、工程实施报告、工程质量测试报告、工程检查报告、应用测试报告、材料清单、工程实施质量与平安检查记录、操作使用说明书、售后效劳保证文件、培训文档； 3、 软件开发文档：需求调研报告、需求说明书、概要设计说明书、详细设 计说明书、数据要求说明书、数据库设计说明书、测试方案、测试分析报告、程序维护手册、程序员开发手册、用户操作手册； 4、 软件开发管理文档：工程方案书、质量控制方案、配臵管理方案、用户培训方案、质量总结报告、会议记录和开发进度月报、工程开发总结报告。 四 软件已臵于配臵管理之下； 五 系统建设和数据处理符合信息平安的要求，

48、凡涉密信息系统需提供保密主管部门出具的验收合格证书； 六外购的操作系统、数据库、中间件、应用软件和开发工具应符合知识产权及相关政策法规的要求，并有相关的授权使用证书； 七各种设备经加电试运行，工作正常； 八经过监理方、高伟达公司及相关主管部门的同意； 九符合合同或合同附件规定的其他验收条件； 十由高伟达公司向南京银行提出阶段验收申请，同时将与工程验收有关的材料提交到高伟达公司处； 十一南京银行审核材料同意工程阶段验收。 1.1.6.8.3. 阶段验收内容 按照工程合同以及工程的阶段划分，核实硬件设备是否齐全、硬件设备是否符合平安要求、系统功能是否符合合同要求、工程文档是否符合文档撰写要求。 结

49、合本工程特点，我们建议的阶段验收分为： 1. 平台建设完成阶段验收； 2. 数据、技术相关标准制定完成后阶段验收； 3. 各业务系统接入总线完成后阶段验收等。 同时根据工程的不同开发阶段，穿插对开发过程形成的文档进行验收，例如： 1. 工程需求评审验收； 2. 工程概要设计验收； 3. 工程详细设计验收； 4. 工程测试方案验收； 5. 工程上线方案验收等。 1.1.6.8.4. 阶段验收形式 阶段验收只进行功能性测试。 1.1.6.8.5. 阶段验收步骤 一准备阶段。工程监理单位组织人员根据阶段验收内容对工程进行验收需求分析，编写验收方案书并提交给南京银行、高伟达公司单位审定。 二成立阶段验

50、收小组。高伟达公司负责组织成立工程验收小组。 三工程验收实施。阶段验收小组按本方法第二章验收方法和标准进行验收。 四提交阶段验收报告。工程检查完毕，验收小组对工程系统设计、建设质量、设备质量、软件运行情况等做出全面的评价，并撰写阶段验收告提交给高伟达公司。 五高伟达公司根据阶段验收报告，对合格的工程准许投入试运行；对不合格的工程提出存在问题及整改时限，以书面形式通知承建单位，承建单位在通知的时限内完成整改后，可再次提出阶段验收申请。 1.1.6.9 终验内容及程序 1.1.6.9.1. 终验目的 对经过一段时间试运行后的工程进行全面审核。 1.1.6.9.2. 终验条件 高伟达公司申请工程终验

51、，应当符合以下条件： 1、阶段验收合格后，高伟达公司按照南京银行要求完成中标的系统开发并经南京银行上线运行3个月之后，南京银行确认能够完全满足南京银行的业务需求并且能够实现本次招标工程的建设目标，完全符合南京银行的技术要求并且能够实现本招标工程的系统要求，系统运行稳定。 2、高伟达公司按照南京银行要求完本钱次招标工程的业务与技术向南京银 行的完全转移，包括向南京银行提供中标标的的培训。 3、高伟达公司按照南京银行要求向南京银行完成中标标的所有相关的源代码、工程文档及其介质的移交工作。 4、系统在试运行期间没有出现问题，或出现的问题已经解决； 5、验收审核材料齐全：除阶段验收时涉及的审核材料外，

52、还有工程建设总结评价报告组织与实施协调、试用总结报告、用户使用反响意见、工程培训方案、工程培训总结，以及由测试资质的第三方单位出具的测试报告； 6、高伟达公司向南京银行提交终验申请、验收方案书及终验审核材料； 7、南京银行审核材料后同意工程终验。 1.1.6.9.3. 终验内容 按照工程合同，对工程建设的各种设备进行核实；对工程建设系统进行终验验收测试，并进行用户使用满意度调查；对工程建设的相关材料进行审核。 1.1.6.9.4. 终验形式 终验验收测试内容有功能测试和性能测试，其中性能测试包括执行效率、资源占用、稳定性、平安性、兼容性、可扩展性、可靠性、并发性、疲劳强度等，涉及到网络的工程性能测试应分为客户端性能测试、网络性能测试和效劳器端性能测试三个方面。 1.1.6.9.5. 终验步骤 准备阶段。根据终验内容由工程监理协助高伟达公司单位制订终验方案并