摩根大通银行信用卡系统
投标人名称：武汉佰钧成技术有限责任公司日 期: 技 术 方 案
二○一二年二月一日
前 言
根据项目要求，武汉佰钧成技术有限责任公司需要完成摩根大通银行信用卡系统的开发、测试、试运行、直至最终的交付使用，负责人员的培训和后期的维护等工作，通过我们对招标文件的分析和理解，我们认为要完成这些工作任务，必须对该项目的业务现状及未来发展目标有较为全面的理解，并有能力进一步的深入细化。以此为基础，我们提出本系统承建方案。
为了能帮助各位领导快速的了解整个技术方案编写的思路，我们将各个部分和章节进行了概括性的描述，具体如下：
第一部分，技术方案。在第一部分中，主要阐述了公司对本项目用户需求的理解、对项目建设目标和原则的理解，提出系统设计的指导思想，以及系统架构的设计方案，功能的设计以及安全设计方案，关键技术点的实现方法等。
第二部分，项目实施及服务方案。在第二部分中，主要陈述了公司在本项目建设过程中将严格参照ISO9001质量保证体系规范和CMMI管理体系，体现我们专业实施能力和项目组织、管理能力；同时，还包括对项目组的人员组成结构，以及对项目的总体计划安排，对项目进度、质量的控制，培训及售后服务的承诺等。
作为湖北省IT服务的主流企业，武汉佰钧成技术有限责任公司有能力、有实力承建该项目，为摩根大通银行信用卡系统的建设贡献我们的绵薄之力。
最后，预祝本次项目工作取得圆满成功！
武汉佰钧成技术有限责任公司
2012年2月
目 录
第一部分 技术方案 ..................................................................... 7 1. 总体设计 .......................................................................... 8 1.1. 总体设计原则 .................................................................. 8 1.2. 总体设计思路 .................................................................. 8 1.2.1. 采用统一顶层设计方法...................................................... 8 1.2.2. 顶层设计方法的含义........................................................ 8 1.2.3. 顶层设计对象 ............................................................. 9 1.2.4. 采用成熟快速开发平台..................................................... 10 1.3. 界面设计原则 ................................................................. 10 1.4. 技术架构 ..................................................................... 11 2. OS／390系统 ...................................................................... 11 2.1. OS／390技术特点 ............................................................. 11 2.2. 信用卡系统结构 ............................................................... 12 3. 需求分析 ......................................................................... 15 3.1. 总体目标 ..................................................................... 15 3.2. 信用卡系统业务需求分析 ....................................................... 16 3.3. 系统安全需求 ................................................................. 17 4. 相关技术 ......................................................................... 18 4.1. IBM公司的SNA网络技术 ......................................................... 18 4.2. IBM WebSphere MQSeries中间件 ................................................ 18 4.3. CICS中间件 ................................................................... 20 5. 系统的详细设计与实现 ............................................................. 20 5.1. 企业端与银行端的通讯实现 ..................................................... 20 6. 运行环境 ......................................................................... 24 6.1. 软件平台 ..................................................................... 24 6.2. 开发工具说明 ................................................................. 24 第二部分 项目实施及服务方案........................................................... 25 6. 项目组织与管理 ................................................................... 26 6.1. 项目干系人分析 ............................................................... 26 6.2. 项目组织结构 ................................................................. 26 6.3. 主要人员投入 ................................................................. 27 6.4. 佰钧成的项目服务管理体系结构 ................................................. 28 6.4.1. 公司级管理服务体系....................................................... 28
6.4.2. 项目级服务管理体系结构 ................................................... 28 7. 项目实施计划 ..................................................................... 29 7.1. 项目阶段划分 ................................................................. 30 7.2. 项目总体计划 ................................................................. 30 7.2.1. 准备阶段 ................................................................ 31 7.2.2. 需求阶段 ................................................................ 31 7.2.3. 设计阶段 ................................................................ 32 7.2.4. 开发阶段 ................................................................ 32 7.2.5. 集成测试阶段 ............................................................ 33 7.2.6. 试运行、上线及终验阶段 ................................................... 33 7.2.7. 运营维护阶段 ............................................................ 33 7.2.8. 贯穿各阶段的其它任务..................................................... 34 8. 项目成果和交付物 ................................................................. 34 9. 项目风险计划 ..................................................................... 35 9.1. 项目风险分析 ................................................................. 35 9.1.1. 宏观风险分析 ............................................................ 36 9.1.2. 微观风险分析 ............................................................ 37 9.2. 主要风险识别及缓解措施 ....................................................... 39 9.3. 其他风险控制措施 ............................................................. 42 10. 项目测试与验收方案 .............................................................. 44 10.1. 项目测试方案 ................................................................ 44 10.1.1. 测试概述 ............................................................... 44 10.1.2. 测试目标和原则 ......................................................... 44 10.1.2.1. 测试目标 ........................................................... 44 10.1.2.2. 测试原则 ........................................................... 44 10.1.3. 测试组织 ............................................................... 45 10.1.4. 测试内容 ............................................................... 45 10.1.5. 测试步骤 ............................................................... 48 10.1.6. 测试过程进度及质量控制 .................................................. 50 10.2. 验收方案 .................................................................... 50 10.2.1. 概述 ................................................................... 50 10.2.2. 验收标准 ............................................................... 50 10.2.2.1. 验收方案的原则 ..................................................... 50 10.2.2.2. 系统验收标准 ....................................................... 51
10.2.2.3. 问题级别定义 ....................................................... 52 10.2.2.4. 测试通过标准定义 ................................................... 52 10.2.2.5. 测试异常的定义 ..................................................... 53 10.2.3. 验收流程 ............................................................... 53 10.2.4. 验收方式 ............................................................... 54 10.2.5. 验收内容 ............................................................... 54 10.2.5.1. 软件系统 ........................................................... 54 10.2.5.2. 过程文档 ........................................................... 55
11. 项目实施制度和规范 .............................................................. 55 11.1. 实施制度 .................................................................... 55 11.1.1. 决策制度 ............................................................... 55 11.1.2. 沟通汇报制度 ........................................................... 56 11.1.3. 需求管理制度 ........................................................... 56 11.1.4. 变更管理制度 ........................................................... 57 11.1.5. 配置管理制度 ........................................................... 57 11.1.6. 问题管理制度 ........................................................... 57 11.1.7. 文档管理制度 ........................................................... 58 11.2. 实施规范 .................................................................... 59 11.2.1. 质量管理规范 ........................................................... 59 11.2.2. 分析设计规范 ........................................................... 60 11.2.2.1. 系统分析规范 ....................................................... 60 11.2.2.2. 概要设计规范 ....................................................... 61 11.2.2.3. 详细设计规范 ....................................................... 62 11.2.3. 系统测试规范 ........................................................... 63 11.2.4. 系统开发规范 ........................................................... 65 12. 项目质量保证体系 ................................................................ 67 12.1. 质量保证目标 ................................................................ 68 12.2. 质量保证角色与职责 .......................................................... 68 12.3. 质量保证流程 ................................................................ 70 12.4. 质量保证活动 ................................................................ 70 12.4.1. 协助项目过程定义 ....................................................... 70 12.4.2. 协助项目计划的编写...................................................... 70 12.4.3. 质量保证计划编写与确认 .................................................. 71 12.4.4. 项目过程和产品检查...................................................... 71
12.4.5. 问题上报 ............................................................... 75 12.4.6. 质量保证工作总结 ....................................................... 76 13. 项目进度控制方案 ................................................................ 77 13.1. 项目进度跟踪 ................................................................ 77 13.2. 项目进度分析 ................................................................ 78 13.3. 项目进度控制 ................................................................ 78 14. 售后服务承诺 .................................................................... 79 14.1. 服务承诺 .................................................................... 79 14.1.1. 质量保证承诺 ........................................................... 79 14.1.2. 免费技术咨询 ........................................................... 80 14.2. 服务响应承诺 ................................................................ 80
14.2.1.1. 故障等级划分 ....................................................... 80 14.2.1.2. 服务响应承诺 ....................................................... 81 14.3. 服务目标 .................................................................... 81 14.4. 服务策略 .................................................................... 82 14.5. 服务方式 .................................................................... 82 15. 培训保障方案 .................................................................... 84 15.1. 培训承诺 .................................................................... 84 15.2. 培训目标和内容 .............................................................. 85 15.2.1. 培训需求 ............................................................... 85 15.2.2. 培训目标 ............................................................... 85 15.3. 培训类别 .................................................................... 86 15.4. 培训课程 .................................................................... 87 15.5. 培训方式 .................................................................... 87
武汉佰钧成技术有限责任公司
第一部分 技术方案 摩根大通银行信用卡系统建设项目
- 7 -
武汉佰钧成技术有限责任公司
1. 总体设计
1.1. 总体设计原则
1、实用性原则
系统建设中，兼顾实用性、可靠性、安全性、先进性、可扩充性，在满足功能要求的前提下，尽可能降低建设成本和运行成本。在系统建设特别是应用系统建设中，采用平台化、组件化的思想，充分利用成熟的应用支撑平台及中间件技术，分层实现，减少系统建设和维护工作量，提高系统的整体质量和效率，节省投资，应对变革。
2、有效性与扩展性原则
在多个层次的建设任务和建设阶段划分过程中，应充分体现阶段建设的有效性，尽量先满足具备条件的建设需求，将条件不成熟的建设任务后置，以免返工；建设过程应遵循一个时期内的有效性，够用、好用即可，避免在有限的时间内无限地扩张建设范围；同时在有效的基础上应考虑未来一定时期内的扩展性，减少后期投入。
3、采用灵活的平台样式，页面中栏目可以灵活摆放，栏目可以灵活定义，风格样式可以灵活选择。
4、平台能够适应一定的需求变化，能快速响应信息需求和功能需求的变化。 5、操作简便，后台管理功能设计合理；具备良好的导航能力。
1.2. 总体设计思路
1.2.1. 采用统一顶层设计方法 1.2.2. 顶层设计方法的含义
顶层设计方法主要是用系统论的方法，对考试院信息系统建设的各个方面、各个层次、各种参与力量、各种正面的促进因素和负面的限制因素进行统筹考虑，理解和分析影响系统建设的各种关系，从全局的视角出发，进行整体技术结构的设计，并做出各种管理和技术决策，提出体制和业务的改进建议。
不管是业务处理还是内部管理，顶层设计对信息化建设的成效都起着至关重要的作用：在系统建设过程中，如果说没有统一的顶层设计、规划的话，那么各系统各自为政，软件、接口、体系标准都不一样，会导致互联互通实现不了，业务无法协同，内部办公效率低下。
摩根大通银行信用卡系统建设项目
- 8 -
武汉佰钧成技术有限责任公司
顶层设计中的“顶层”包含三个层次：
第一层、从整体和全局出发。
顶层设计的首要视角是要跳出局部环境的束缚和影响，站在全系统互联和全网通用的整体高度和全局视野，去分析决定应用系统建设过程中的基础、通用、平台型模块。
比如说交易、服务资源目录体系，在应用互联互通的时代，交易、服务资源目录不但要供自己本系统、本单位使用，可能还要供相关联系统、外部单位使用，系统之间的接口必须统一兼容。如果交易、服务资源目录这个交易调用、服务共享的关键部件，在内容、格式、接口、协议上是彼此不同的，则违背了建设资源目录的初衷，必将导致形成新的孤立割裂、群雄并存的结局。
第二层、从整体业务框架、顶层流程入手。
顶层设计的重点是业务、是流程。应用系统开发失败的教训一再揭示正确全面描述用户需求，尽力满足用户需求的重要性，这里的用户需求，多半重点不在用户的操作需求，而是用户业务需求。
顶层设计就是用信息工程的方法，从宏观上对业务需求进行收集、梳理和描述，把业务需求按层次、体系化呈现出来。顶层设计中的业务，不是进行业务决策，但是顶层设计的输出结果，将以丰富清晰的业务框架，帮助和推动业务决策，业务设计，业务改进和改革。
第三层、从应用系统类型划分、整体架构规划入手。
结合业务框架、顶层流程，规划合理的应用系统类型划分、整体架构规划，是顶层设计在应用系统设计过程中技术层面关心的主要问题。
规划合理的应用系统类型划分，可确保基于业务框架的系统功能切分的合理性。可避免后续重复的系统建设，业务功能建设；整体架构规划可确保各类应用系统的建设在技术统一、平台统一、流程一致、方法一致的基础上实现系统之间功能接口、数据接口的一致性。 1.2.3. 顶层设计对象
业务和技术，正是顶层设计的两大范畴。
1、 顶层设计中所指的业务，不但包括业务职能、业务结构、业务流程，还要包括
业务体制、业务法律法规、业务模式、业务布局等事情。
摩根大通银行信用卡系统建设项目
- 9 -
武汉佰钧成技术有限责任公司
2、 顶层设计中所指的技术，主要是从全局和整体出发，对技术战略、技术框架和
技术标准的分析和定义，还包括为了减少重复建设，增加资源（业务需求分析、数据模型、软件模块、系统组件设计素材等等）重用性，以模块化服务的形式，来定义所有的应用系统。
进行顶层设计，就是围绕着系统建设中上述业务和技术的种种问题，用系统规范的科学理论方法，描述业务和技术的状态，理清业务和技术中的各种关系，确定建设目标，选择和制定实现目标的路径和战略战术，从信息化的“今天”走向信息化的“明天”。 1.2.4. 采用成熟快速开发平台
在本方案中，我们将采用IBM强大、成熟的开发应用平台，利用平台提供的应用支撑框架，如页面布局管理、工作流引擎、数据交换、页面流转、事务管理等，以及大量成熟业务、技术构件，如组织机构、用户权限、系统监控等，能够快速搭建各类业务应用，有效降低应用系统开发的进度风险和质量风险。
1.3. 界面设计原则
1、 用户原则
访问界面设计首先要确立涉众用户类型，通过划分不同层次的用户类型，分析其不同需求，从多方面加以设计实现，提供用户自定义界面服务功能。
2、 简洁性原则
界面反映的信息量要求最小，界面设计要尽量减少用户记忆负担，采用有助于记忆的设计方案，使用户操作更容易短期上手。
3、 易用原则
软件界面设计要直观、对用户透明，最终用户接触软件后对界面上对应的功能一目了然，便于用户的理解、学习、掌握，不需要专业培训就可以方便使用系统。
4、 友好性原则
人机界面友好，具有很强的在线帮助功能，方便操作和维护。要对用户的操作命令做出反应，帮助用户处理问题，提供智能业务提醒功能，辅助业务流程工作。系统要设计有恢复出错现场的能力，在系统内部处理工作要有提示，尽量把主动权让给用户。
5、 一致性原则
界面风格统一设计、统一实现。使操作界面清晰，美观，干净，直观，前后操作连贯。在界面
摩根大通银行信用卡系统建设项目
- 10 -
武汉佰钧成技术有限责任公司
设计中应该保持界面的一致性，确立界面设计标准。包括显示信息、错误提示、快捷方式、页面布局、交互方式等标准，使系统风格始终保持一致。
1.4. 技术架构
基于本文前面章节所述设计原则，按层次化思路，系统技术架构的层次结构如下图所示：
访 问 界 面 层业 务 应 用 层应 用 支 撑 层数 据 资 源 层系 统 设 施 层网 络 通 信 层 系统技术架构由界面访问层、业务应用层、应用支撑层、数据资源层、系统设施层、网络通信层和支撑体系七个层次构成。其中，支撑体系又分为标准规范体系、安全保障体系和运维管理体系。
支撑体系|标准规范体系支撑体系|安全保障体系支撑体系|运维管理体系2. OS／390系统
2.1. OS／390技术特点
OS／390操作系统 是IBM公司最引以为豪的系统软件，它秉承和扩展了MVS的传统强势，是一个具有整合性功能的集成企业服务器操作系统。
它将开放的通讯服务器、分布式数据和文件服务、并行复合系统支持、面向对象程序设计、DCE以及开放应用程序接口集成为一个产品，为用户提供了一个集成化的、具
摩根大通银行信用卡系统建设项目
- 11 -
武汉佰钧成技术有限责任公司
有可扩充性的系统。在体系结构上基于之前的System／370做了一系列改进，向量处理、新的通道结构ESCON、保密硬件措施以及 SCE系统控制单元技术使得OS／390具有更强大的处理能力。OS／390通过逻辑分区和虚拟技术可以把多个服务器上的应用集中到一台大型主机上实现集中管理，消除分散系统开销难以预见的困难，管理成本清楚可见。同时，大型机区别于UNIX服务器系统的最关键因素在于大型机在支持大型工作负荷和大规模用户数方面的能力显著。在开放的运行环境下，OS／390系统具有自动工作负载管理功能，根据工作量自动调整资源分配，结合OS／390最佳系统恢复能力及资料一致性机制，在出现故障时能保持最大限度的系统继续可用，确保客户至上的服务品质。OS／390拥有可进行并行数据严谨分析的安全网络及时髦的网络计算功能，可并行快速地分析和处理企业级数据，保证对动态商业环境灵活反应，完成商业重要度管理。一直以来，OS／390始终保持向上兼容与开放性。目前，IBM的z系列可以支持Java、J2EE等新标准；WebSphere等电子商务应用程序服务器软件以基于JAVA的Servlet引擎为基础，可以使用 IBMConnector系列访问大型机的资源(如CICS和IMS)；OS／390结合MQ、CICS等中间件软件，可完成强大的多人、多工在线联机交易功能、批处理、数据挖掘、Web服务等功能。
2.2. 信用卡系统结构
银行的信用卡系统业务负载较高，峰值交易量巨大，且对数据的存储、安全性与处理速度有较高的要求。基于OS／390的上述技术特点和优势，提出了一种基于OS／390大型机平台的银行信用卡系统模型，这里介绍其总体结构和技术特征。
1.2．1总体业务结构模型。
(1)总体业务结构模型。持卡人、收单银行、发卡银行和卡片组织之间的关系如下： 申请人先向发卡银行申请信用卡，发卡银行按一定策略对申请者的信用状况进行评估，对符合条件的申请人核发信用卡。持卡人取得信用卡后即可到特约商店进行消费，每笔消费交易之前，特约商店会发起授权请求，通过信用卡国际组织授权清算网络向发卡银行请求授权，发卡银行根据卡片的信用状况决定是否给与授权，并将结果反馈给特约商店。特约商店取得授权后，即可为持卡人提供相应服务，持卡人要对消费行为及金额进行确认。之后，特约商店会依照消费金额向收单银行请款，收单银行会将钱先付给特约商店，再通过信用卡国际组织的清算网络向发卡银行请求清算，发卡银行确认后，将钱付给收单银行，并将消费金额计人持卡人帐户。当持卡人账单日到时，通过计算机
摩根大通银行信用卡系统建设项目
- 12 -
武汉佰钧成技术有限责任公司
系统将持卡人本月全部交易金额进行汇总，打印账单给持卡人，要求缴款。持卡人收到账单后，经确认无误，通过发卡银行的缴款通路缴纳消费款项。当有争议发生时，会依照授权码、消费签单，进行调单扣款作业处理。若持卡人在规定时间内未按要求交清所欠款项，发卡银行要对持卡人进行催收作业及一系列后续处理。在信用卡使用的整个循环中，发卡银行的计算机系统要完成征信发卡、授权、帐务帐单、催收调扣等主要模块的功能。
具体业务流程如图1所示。
图1 总体业务结构模型图
(2)总体系统架构。信用卡业务整体需求的特殊性决定了其计算机系统架构的复杂性。授权请求交易过程必须在线及时处理，同时持卡人会在全球各地、任何时刻进行刷卡消费活动，能否及时快速对如此大量、密集、不间断的授权交易请求作出准确、高效的响应，是衡量发卡银行计算机系统响应处理能力的重要指标同时，在计算机系统出现故障和异常时继续保证授权交易的正常进行是必须解决的关键问题。在后续请款、清算、帐务账单、催收和调扣处理过程中，系统中要存储大量关键数据，以供应用系统结合业务处理逻辑对数据进行加工处理，为银行提供各种需要的结果。如何管理好这些海量数据的存储和加工，在时空效率上满足业务要求，一直是计算机系统处理能力的瓶颈。针对上述问题，结合最新ES9000系列大型机技术发展的成果，在OS／390操作平台下设计新的计算机应用系统的整体体系架构如图2所示
摩根大通银行信用卡系统建设项目
- 13 -
武汉佰钧成技术有限责任公司
图2 总体系统架构图
在图2中，数据处理服务器采用 IBMES／9000大型机，应用系统中大量业务数据的存储和加工处理、数据完整性与安全性由OS／390下的VSAM文件系统管理，各交易通路的数据获取及维护请求通过OS／390下的在线交易处理中间件CICS技术实现。联机前置处理服务器采用HP公司的TANDEM机，完成OLTP前置处理和备援功能，当ES／9000主机进行批量作业处理和有故障时完成代行功能，处理授权交易请求。各交易通路有自己的管理中心，通过各自的前置系统连接各种终端设备，再将业务进行处理、转发和传送。NETBANK SERVER、CALL CENIER 和 D0WNL0ADSERVER完成网络银行、电话银行及其他各种交易通路数据格式的转换及可靠连接传输功能。与VISA和 MASTER国际组织之间的信息交互由VAPSERVER和MIPSERVER承担，AS／400的交换网络承担连外通路的收单功能，系统中对各业务关键节点进行双备份，比如信用卡中心的局域网等。但是，为了简明起见，没有画出。在上述架构中，整个系统既能集中管理信用卡业务的海量数据，同时又能对各交易通路的在线服务请求作出快速、准确的响应，最大程度地满足了信用卡业务整体需求。
摩根大通银行信用卡系统建设项目
- 14 -
武汉佰钧成技术有限责任公司
3. 需求分析
3.1. 总体目标
在信用卡系统中，针对信用卡业务的特点，企业提出可以通过网上单笔或批量两种方式对本企业账户下属的所有职员的信用卡进行报销款项转账业务并可以完成本企业账户下属的所有职员的信用卡快速申请和授信额度的灵活变更等信用卡辅助使用功能。通过对以上企业提出的需求进行分析，设计信用系统是应主要实现以下几方面的功能：
>系统的主旨是面向重点企业客户，用户通过Intemet接入。 >支持企业付款的单笔录入、批量导入，使系统更灵活，可用性更强
>实现合笔从企业对公账户扣款，并逐笔往相应的信用卡中入账，即合笔扣账，逐笔入账。
>实现根据不同企业的性质要求灵活定制企业端的复核和授权方式。
>为实现及时完成企业报账划款的要求，必提高系统的安全性，实效性，信用卡系统要实现联机会计业务，即联机的会计扣账和冲账业务。
>通过第三方CA产品安全保障对企业身份验证及付款指令的加密传输。
>将原来分行与支行间资金的手工清算变为分行与支行间逐笔实施清算，将所有企业的对公账户扣款直接划归在分行卡部信用卡专户中，以完成逐笔入个人信用卡账户的功能。
>实现当批量报账中存在异常卡的反馈和后续处理。 >实现在网信用卡业务的5×8小时的联机服务。
>实现信用卡账务系统批量接口，批量完成逐笔入账，提高处理效率。
>银行处理端规范业务操作，相关传票、分录、特种转账传票由系统自动生成借口文件传到OnDemand报表系统中，减少手工操作风险。
>提供系统的银行管理端，完成客户资料维护以及企业证书的管理。 >提供多种方式的查询，以方便企业的管理和银行的管理。
摩根大通银行信用卡系统建设项目
- 15 -
武汉佰钧成技术有限责任公司
3.2. 信用卡系统业务需求分析
2.2.1信用卡快速申请 1．业务描述
是指客户通过网上信用系统向银行端发送申请办理信用卡的电子信息，银行对电子信息进行下载处理后，经过申请处理、审批、录入和开户等流程完成制卡手续，待领卡时补齐申请原件的业务处理。
2．处理方式
(1)由公司指定人员在信用卡系统填制信用卡电子申请表，要素包括：姓名、性别、身份证号码、家庭地址、部门名称、联系电话、账单地址等字段。
(2)填妥后，附上申请人身份证扫描件发送至主管进行审批，审批后，回传至经办。由经办将审批后的申请表和身份证扫描件发送至银行端。
(3)银行接收申请件后办理审批和制卡手续。 (4)领卡时补齐申请原件。
2.2.2卡资料及授权额度等信息变更 1．业务描述
是指客户通过信用卡系统提交授信额度的增加与修改、公司基本资料的修改、账单地址的变更等信息，银行接收客户提交的申请信息进行下载打印，并视作为有效申请，按正常流程进行处理的业务操作。
2．处理方式
(1)由公司指定人员在信用卡系统填写授信额度、持卡人基本资料和账单地址变更申请单。
(2)填妥后，将《额度申请表》发送至主管进行核批，核批后，回传至经办。由经办将核批后的申请单发送至银行端(其他变更信息不需复核)。
(3)银行接收申请信息后，将下载打印件直接作为申请原件，同时办理相关变更手续。 2.2.3 多元化的查询 1．回单查询
输入日期及当日的报账批号即可查询当天此批号报账业务的银行处理情况，如果当天银行回单中有错误记录，则缺省显示出来，方便企业及时掌握报账处理情况广采取相
摩根大通银行信用卡系统建设项目
- 16 -
武汉佰钧成技术有限责任公司
应的措施。也可以根据日期和卡号查询某一张公务卡报销处理的情况。
2．综合查询
提供一个全面的查询功能。可能多选择的组合模糊查询，更方便企业的使用。强化了网上公务卡的企业财务的管理功能。
3.3. 系统安全需求
对处理不同业务的企业端操作人员应根据不同的级别和操作权限对身份进行验证(登录财务中心系统必须持有CA认证证书，该证书应达到相应技术安全认证标准)，保证交易安全和身份认证的有效性和合法性。
一、系统登录控制与管理 1．安全证书验证
用户登录网上公务卡系统，必须通过安全和身份验证。 2．签入系统
通过用户名和密码登录系统。 二、企业端用户证书级别和权限限定 1．经办权限
(1)创建、修改报账文件和相关信息更改申请文件
(2)可以发送经复核后的报账文件、客户基本资料修改申请和账单地址变更申请 (3)不可对报账文件进行复核。 (4)不可对复核批准后的文件进行修改。
(5)不可发送未经复核的报账文件和授信额度修改申请文件。 2．主管权限
( 1)只可对相关申请文件进行复核，不可对文件进行修改。 (2)不能发送所有文件。
3．出纳权限：只能发送报账文件。 三、所有的交易数据需要加密传输
摩根大通银行信用卡系统建设项目
- 17 -
武汉佰钧成技术有限责任公司
4. 相关技术
4.1. IBM公司的SNA网络技术
SNA (Systems NetworkArchitecture) 系统网络结构，是IBM公司开发的网络体系结构，是一组大型网络标准和协议，包含着IBM大型机网络环境中配置和管理系统资源的服务，SNA定义了大型机主机控制终端的集中体系结构，是IBM大型机和中型机的主要联网协议，在IBM主机环境中得到广泛的应用。SNA这个体系结构中，包括大型计算机系统(ES／9000、S／390等)、中型机计算机系统(AS／400)、3270终端和台式计算机，并有一个使这些系统与主机系统通信或系统间相互对等通信的策略。SNA定义了数据通信网络的逻辑架构，网络资源之间进行同步通信的协议，网络上传输的信息格式；描述了网络上控制网络资源，进行网络配置，传输信息等操作次序。SNA网络由物理部分(physical components)和软件部分(software components)组成，其中软件部分有访问方式(ACF／VTAM)，应用子系统(CICS，components)组成，其中软件部分有访问方式(ACF／VTAM)，应用子系统(CICS，IMS)，用户应用程序和网络控制程序(ACF／NCP)。
SNA的硬件部件和运行在其上的软件称为“节点(node)”，它们之间用数据链路(datalinks)互连。网络上的节点是端点或网络上的连结点。
SNA设计的主要目的是端到端的通信，以及让用户应用程序远离复杂的数据通信系统，使用户感觉到数据通信系统的透明性。端用户通常是一台终端或者是主机上的应用程序。SNA网络就是为端用户提供相互之间通信的服务。
SNA中被数据链路连接起来的物理部分(SNAphysical components)称之为SNA节点(SNAnode)。SNA提供一种以主机为中心的通信架构，定义了一些逻辑部件以实现这些功能。LU(109ical unit)用来处理端到端的通信；PU(physical unit)是在SNA节点上用来管理物理资源的；SSCP(system servicescontrol poim)作为网络中访问控制的中心；DLC(data link contr01)用来管理数据传输的链路；PC(pathcontr01)用来处理数据在SNA网络中传输的路由。
4.2. IBM WebSphere MQSeries中间件
在网上公务卡系统的设计与实现中，需要从位于防火墙以外的网上公务卡企业端WEB服务器发送业务数据包到位于两层防火墙以内网上公务卡银行端服务器上，在此传
摩根大通银行信用卡系统建设项目
- 18 -
武汉佰钧成技术有限责任公司
输过程中，由于网络状况等因素使得业务数据包的传输可靠性、高效率和安全性难以得到有效的保障，因此，在实现中我们使用了IBM WebSphereMQ Series中间件作为工具对报文进行传输，有效地实现了远程数据包的可靠传送。
MQ Series是IBM的商业通讯中间件(Commercial Messaging Middleware)。MQ Series提供一个具有工业标准，安全，可靠的信息传输系统。它的功能是控制和管理一个集成的商业应用，使得组成这个商业应用的多个分支程序(模块) 之间通过传递消息完成整个工作流程。MQ Series基本由一个消息传输系统和一个应用程序接口组成，其资源是消息和队YlJ(Messaging andQueuing)
IBMWebSphere MQSeries中间件有着以下四方面的优点：
1．统一接口，跨越IBM和非IBM平台。简单的PUT和GET动词在MQSeries支持20种mM和非IBM平台上完全相同。使得MQ Series提供了这样的特性：目标应用程序位置的透明性(targetapplication location transparency)。对于一个应用程序的开发者，他需要知道的全部只是队列的名字，这个队列与一个特定的服务有关，而与系统的平台或系统在什么地方无关。
2．使开发人员避开网络的复杂性。因为MQ Series负责处理所有的通讯，开发人员不必编写任何通讯方面的程序。并且编程和调试非常简单和直接，不需要具体的系统和通讯方面的知识。尤其在C／S模式的应用时，开发人员可以集中精力在与业务有关的客户端和服务器端的应用，而不必考虑操作系统和通讯，特别是底层的网络通讯，节省大约50％到75％的通讯编程工作。
3．处理不依赖时间的限制。意思是说在信息创建和发送时，信息的接收方或到接收方的通道不需要激活。不受时间的限制增加了处理的灵活性，允许事务处理在它们想做或有时间做时，彼此通讯程序可以运行在不同的时间。这样程序的运行是独立的，如果逻辑允许，它们不必等待其它程序的应答而继续工作，利用这种异步处理功能，可以更有效的使用资源，更灵活的处理模式，应用处理可以是独立的，并行的，重叠的，从而改进用户服务。
4．给分布式处理提供的强健的中间件。包括逻辑工作单元支持(109icalunit of work)，备份和恢复机制，大信息传递和高性能等特点。其中最重要的是确保信息传输，意思是一旦MQ Series接受一个信息传输的任务，会确保信息被传送到目标平台。信息的传输是一次且仅一次．另外，强健的中间件机制保证业务数据一致性，并可在系统发
摩根大通银行信用卡系统建设项目
- 19 -
武汉佰钧成技术有限责任公司
生故障时，及时恢复，业务不会受到影响。
4.3. CICS中间件
CICS(Customer Information Control System)客户信息控制系统是IBM公司的联机事务处理系统，作为一种交易中间件被广泛应用于当今信息产业领域的各种事务处理环境中。交易中间件也称为事物处理中间件，是专门针对联机交易处理系统而设计的，它是操作系统和应用程序之间的一层软件平台，主要为上层的应用程序提供一致的应用编程接口，即提供透明访问操作系统的功能和系统管理辅助工具等。CICS作为一个强有力的联机事务处理中间件，具有商业级事务管理器要求的整合性、可恢复性、安全性和可用性，具有跨平台的广泛的可操作性，提供跨平台的API，形成可移植的应用和开发技术。在联机事物处理系统中，CICS通过标准的)【A接口同数据库之间进行数据通讯，完整的体系结构保证了CICS服务器与数据库之间连接的灵活性，并保证着事物完整性和数据一致性】。CICS最初来源于主机环境，现在运行于很多IBM和非IBM平台和各种不同的网络环境(从几台微机到几千个终端)。在任何一个应用CICS的硬件或软件平台上，程序员可以通过CICS应用程序接口(API)进行程序设计调用CICS应用，而且可以在不同的系统平台上进行移植。CICS家族的每一个产品都有良好的继承性，兼容家族中其他产品，并且能够通过网络进行彼此远程调用。在本系统的设计过程中，网上公务卡银行端与会计主机之间即采用了CICS中间件来保证交易的一致性。
5. 系统的详细设计与实现
5.1. 企业端与银行端的通讯实现
一、IBM WebSphere MQSeries中间件的基本组成描述有以下几方面： 1．队列管理器
队列管理器是MQ系统中最上层的一个概念，由它为我们提供基于队列的消息服务。 2．消息
在MQ中，我们把应用程序交由MQ传输的数据定义为消息，我们可以定义消息的内容并对消息进行广义的理解，比如：用户的各种类型的数据文件，某个应用向其它应用发出的处理请求等都可以作为消息。
消息有两部分组成：
摩根大通银行信用卡系统建设项目
- 20 -
武汉佰钧成技术有限责任公司
消息描述符(MessageDescription或Message Header)，描述消息的特征，如：消息的优先级、生命周期、消息Id等；
消息体(MessageBody)，即用户数据部分。在MQ中，消息分为两种类型，非永久性(non-persistent)消息和永久性(,persistent)消息，非永久性消息是存储在内存中的，它是为了提高性能而设计的，当系统掉电或MQ队列管理器重新启动时，将不可恢复。当用户对消息的可靠性要求不高，而侧重系统的性能表现时，可以采用该种类型的消息，如：当发布股票信息时，由于股票信息是不断更新的，我们可能每若干秒就会发布一次，新的消息会不断覆盖旧的消息。永久性消息是存储在硬盘上，并且记录数据日志的，它具有高可靠性，在网络和系统发生故障等情况下都能确保消息不丢失、不重复。
二、在MQ中，还有逻辑消息和物理消息的概念。利用逻辑消息和物理消
息，我们可以将大消息进行分段处理，也可以将若干个本身完整的消息在应用逻辑上归为一组进行处理。
队列
队列是消息的安全存放地，队列存储消息直到它被应用程序处理。 MQ消息队列的工作方式如下所述：
(1)程序A形成对消息队列系统的调用，此调用告知消息队列系统，消息准备好了投向程序B；
(2)消息队列系统发送此消息到程序B驻留处的系统，并将它放到程序B的队列中； (3)适当时间后，程序B从它的队列中读此消息，并处理此信息。 由于采用了先进的程序设计思想以及内部工作机制，MQ能够在各 种网络条件下保证消息的可靠传递，可以克服网络线路质量差或 不稳定的现状，在传输过程中，如果通信线路出现故障或远端的主 机发生故障，本地的应用程序都不会受到影响，可以继续发送数据， 而无需等待网络故障恢复或远端主机正常后再重新运行。 2． 通道
通道是MQ系统中队列管理器之间传递消息的管道，它是建立在物理的网络连接之上的一个逻辑概念，也是MQ产品的精华。
在MQ中，主要有三大类通道类型，即消息通道，MQI通道和Cluster 通道。消息通道是用于在MQ的服务器和服务器之间传输消息的，需
摩根大通银行信用卡系统建设项目
- 21 -
武汉佰钧成技术有限责任公司
要强调指出的是，该通道是单向的，它又有发送(sender)，接收 (receive)，请求者(requestor)，服务者(server)等不同类型，供 用户在不同情况下使用。MQI通道是MQ Client和MQ Server之间通 讯和传输消息用的，与消息通道不同，它的传输是双向的。群集 (Cluster)通道是位于同一个MQ群集内部的队列管理器之间通讯使 用的。
三、IBM WebSphere MQSeries的工作原理
IBMWebSphereMQSeries的工作原理如图4.1所示：
图4-1IBM WebSphere MQSeries的工作原理
首先来看本地通讯的情况，应用程序A和应用程序B运行于同一系统A，它们之间可以借助消息队列技术进行彼此的通讯：应用程序A向队列1发送一条信息，而当应用程序B需要时就可以得到该信息。
其次是远程通讯的情况，如果信息传输的目标改为在系统B上的应用程序C，这种变化不会对应用程序A产生影响，应用程序A向队列2发送一条信息，系统A的MQ发现Q2所指向的目的队列实际上位于系统B，它将信息放到本地的一个特殊队列一传输队YU(Transmission Queue)。我们建立一条从系统A到系统B的消息通道，消息通道代理将从传输队列中读取消息，并传递这条信息到系统B，然后等待确认。只有MQ接到系统B成功收到信息的确认之后，它才从传输队列中真正将该信息删除。如果通讯线路不通，或系统B不在运行，信息会留在传输队列中，直到被成功地传送到目的地。这是MQ最基本
摩根大通银行信用卡系统建设项目
- 22 -
武汉佰钧成技术有限责任公司
而最重要的技术——确保信息传输，并且是一次且仅一次(once．and．only-once)的传递。
MQ提供了用于应用集成的松耦合的连接方法，因为共享信息的应用不需要知道彼此物理位置(网络地址)；不需要知道彼此间是怎样建立通信：不需要同时处于运行状态；不需要在同样的操作系统或网络环境下运行。
四、MQ的架构
网上公务卡企业端服务器与网上公务卡银行端的处理服务器之间的通讯是通过中间件IBMWebSphereMQ Series实现的
在企业处理服务器中，交易报文的转发是其最重要的功能，在银行处理服务器的通讯中，我们使用了IBM WebSphereMQ Series消息中间件来对报文进行传输，下面我们将对MQ的配置、定义以及程序的调用加以详细的讨论。
在企业处理服务器和银行处理服务器，我们分别定义了本地队列和远程队列，分别用于存储远程发送来的交易报文以及将交易报文发送至远程的队列当中。
例如：我们在企业处理服务器中建立了远程队列RQ01用于将企业提交的报账数据整理并组包后通过CH2l通道发送到银行处理服务器的本地队列LQ01中。通过银行处理服务器处理后，将处理结果从远程队列RQ01通过CHl2通道发送到企业处理服务器的LQ01队列中。图4.2说明了MQ队列的具体结构图。
摩根大通银行信用卡系统建设项目
- 23 -
武汉佰钧成技术有限责任公司
图4-2 MQ具体结构图
6. 运行环境
6.1. 软件平台
操作系统：OS/390 应用框架：RPG 数据库：DB2
浏览器：Microsoft Internet Explorer 6.0及以上
6.2. 开发工具说明
整个平台的开发将采用IBM核心的OS/400 RPG银行系统开发工具，并使用最新的版本，使整个平台具备先进的应用环境。
摩根大通银行信用卡系统建设项目
- 24 -
武汉佰钧成技术有限责任公司
第二部分 项目实施及服务方案 IBM银行信用卡系统建设项目
- 25 -
武汉佰钧成技术有限责任公司
6. 项目组织与管理
本章主要阐述了IBM银行信用卡系统项目的干系人、参与整个项目的各方人员的组织结构设置及职能；针对本项目，佰钧成的项目组织结构及岗位职能；以及佰钧成的项目质量保证体系的介绍。
6.1. 项目干系人分析
基于我们对IBM银行信用卡系统项目的理解，我们将以合作伙伴的角色加入到整个项目中。从规划设计、实施、运维等多环节全方位提供信息化建设服务。
从这个基础出发，我们把本项目涉及到干系人分成几类，如下表所示：
干系人名称 主要职责 提出并确认项目需求； 项目建设方（用户方）：IBM 监督工程项目进展情况； 审查和验收项目工作成果； 承建IBM银行信用卡系统项目； 对建设方案中的系统进行设计、开发、实施； 项目承建商：武汉佰钧成技术有限责任公司 协助招标人、项目监理的验收评审工作； 提供系统运行维护服务； 提供培训工作； 按照总体技术方案和详细技术方案的要求完成系统的开发测试工作； 6.2. 项目组织结构
根据本项目“多个组织，一个团队；同一平台，全面沟通”的原则，合理、科学的项目组织结构对于本项目的有效实施将起到事半功倍的效果。
为此，建议建立如下图所示的项目组织结构：
IBM银行信用卡系统建设项目
- 26 -
武汉佰钧成技术有限责任公司
IBM GDC
武汉佰钧成技术 有限责任公司
项目领导 小组 项目经理 项目 开发 实施 小组
注：箭头表示汇报路径。
角色 职责 项目的最高决策机构。 对项目的战略方向、IT规划、重大事件进行决策。 负责有效的将决策信息传达给项目管理小组，监督、管理决策意见的执行结果。 批准项目实施规范，协调内部资源。 项目领导小组将进行不定期会晤。 在整个项目实施期间的担任项目管理和行政管理的工作； 根据项目需要，协调各方关系；贯彻、落实项目领导小组的决策意见，并有效的监督、管理其执行状态； 定期向项目领导小组汇报项目执行情况和总体执行状态。 依据有效的责任范围工作定义进行具体的项目任务实施，接受管理层的直接管理，定期向管理层汇报工作。 人员要求 由IBM银行信用卡系统项目管理领导团队、武汉佰钧成技术有限责任公司项目管理领导人员联合组成。 项目领导小组人员，在所属机构内，必须具有项目总体规划、决策的相应权力。 项目领导小组 项目经理 由武汉佰钧成技术有限责任公司相关人员担任。 项目开发实施小组 根据项目需要，由IBM银行信用卡系统、武汉佰钧成技术有限责任公司的相关人员联合组成。 6.3. 主要人员投入
角色 姓名 工龄 职务 项目领导小组 项目经理 李磊 江龙 许卫国 15 13 15 高管 研发经理 项目经理 IBM银行信用卡系统建设项目
- 27 -
角色 姓名 工龄
职务 武汉佰钧成技术有限责任公司
系统架构师 数据库设计师 代码设计师 代码设计师 代码设计师 代码设计师 质量保证员 配置管理员 美工 测试经理 测试工程师 测试工程师 测试工程师 支持组-客户经理 培训工程师 维护组 张岩 王辉 於艳 朱婧 郝建军 李兴彬 陈新 洪子娟 朱亚 刘博 邓育飞 罗莲 杨丽 余海霞 邵宁 刘流 13 10 5 5 2 2 3 3 5 5 2 2 2 6 7 9 高级工程师 高级工程师 高级工程师 产品技术经理 软件工程师 软件工程师 QA CM 专职美工 测试经理 测试工程师 测试工程师 测试工程师 客户经理 高级工程师 软件工程师 6.4. 佰钧成的项目服务管理体系结构
佰钧成主要从事金融、信用、政府行业信息化建设方面的软件开发、系统集成、软件外包、咨询服务等业务。通过多年的信息化服务，公司积累了丰富的应用建设经验并形成了完善的技术服务体系和服务管理体系。 6.4.1. 公司级管理服务体系
佰钧成基于多年政府信息化建设的服务历程，不断的吸取国内外先进的IT服务管理理念，构建了IT服务管理体系结构。
佰钧成的质量保证体系和项目方法论作为行业应用服务团队处理问题、事故、变更、配置等的行为标准和规范体系；
项目管理团队、系统集成团队、研发团队和基础职能部门为应用服务团队的服务提供级别管理、财务管理、持续性、可用性管理等服务质量提供了有力保证。
佰钧成的决策体系保证了授权、决策渠道的畅通，使得服务管理的内部决策过程快捷、高效。
6.4.2. 项目级服务管理体系结构
信息化建设的主要工作除了依托公司的组织结构和管理体系，更重要的是具体实施信息化建设的项目级服务管理系统，这将直接关系到政府信息化建设的实施效果。
IBM银行信用卡系统建设项目
- 28 -
武汉佰钧成技术有限责任公司
佰钧成建立了完善并有效的项目组组织结构和服务体系。 项目组内部岗位职责依据项目情况确定。一般包括：
✓ 项目领导小组（项目总监）：分项目情况确定，小型项目中一般由部门
（副）经理、咨询专家、技术经理担任；大中型项目或战略项目中一般由副总或行业总监、技术总监、部门（副）经理、咨询专家、高级技术经理担任。
✓ 项目经理：由部门级或公司级管理者担任项目经理。
✓ 客户经理：中小型项目由部门销售团队负责人指定。一般由客户经理担
任。大项目或战略项目由公司项目管理委员会确定。
✓ 架构师：根据项目规模需要设立。由项目经理提名，软件开发中心负责
人批准。
✓ 技术经理：由项目经理提名，软件中心负责人批准。一般由技术经理或
工程师担任，对项目技术实现负责，协助架构师进行总休设计、概要设计，主导详细设计。
✓ 开发经理：由项目经理提名，软件中心负责人批准。一般由公司高级工
程师担任，主导项目编码工作。
✓ 需求经理：由项目经理提名，软件中心负责人批准。一般由公司咨询顾
问和业务经理担任，对项目业务需求负责。
✓ 项目工程师（含开发、测试、维护）：由项目经理提名，软件中心批准。
一般由工程师担任。
✓ 咨询顾问：由项目经理提名，项目管理办公室批准。一般由工程师担任。 注：上述为项目组的标准配置，根据项目规模的大小，上述岗位可以部分或全部合并。
对于本项目，虽然规模不大，但鉴于项目的战略地位，我公司将设立较为全面的组织结构，并配备专职人员。
7. 项目实施计划
本章阐述了IBM银行信用卡系统评论网站项目工程实施的阶段划分、总体实施计划，并详细介绍了各阶段的工作计划及工作内容。
IBM银行信用卡系统建设项目
- 29 -
武汉佰钧成技术有限责任公司
7.1. 项目阶段划分
基于佰钧成软件服务最佳实践模型，依据我们对本项目的理解，定义主要项目阶段划分如下表所示：
编号 1 阶段名称 准备阶段 阶段主要工作描述 2 需求阶段 3 设计阶段 4 5 开发阶段 集成测试阶段 完成项目启动准备工作，主要包括成立项目组织、项目人员的确定、确定项目计划、对项目实施任务的确认、合同的签订、项目实施环境、工具等的准备。 完成需求调研、需求分析工作，为便于与客户方的交流，需求开发系统原型，最终形成需求调研报告和需求规格说明书，由公司方和客户方相关专家完成需求评审。 完成系统的总体设计、详细设计、数据库设计工作、单元测试等测试计划、用例的编制，在系统原型基础上进行进一步的设计、开发，完成最终的设计成果的评审。 以系统设计为基础完成应用软件的编码开发和单元测试工作，此外还有集成测试计划及用例的编制等其他工作。 完成应用软件的集成测试工作并进行评审。 6 7 8 完成系统的试运行工作，对试运行期间发现的问题进行进一步的修改、完善和测试；同时完成系统上线过渡的准备工作，试运行、上线包括数据、软、硬件环境、人员培训等。在试运行结果符合及终验阶段 项目要求后对项目进行最终验收。 同时再上线试运行阶段，将会沿用原来系统中的数据，所做工作包括数据迁移。 在系统验收后进入运营维护阶段，由技术支持及服务人员对运营维护阶段 系统运行提供技术支持服务，对系统业务变化进行修改完善，保证系统正常使用。 包括项目建设中的其他一些任务，这些任务不是在哪个特定贯穿各阶段的阶段完成，而是伴随整个项目实施的过程进行，主要包括数其它任务 据资源的清理和规划设计、系统集成、培训、项目管理等。 7.2. 项目总体计划
依据我们对招标方的实施进度要求的理解，制定了本项目的总体进度计划。项目自合同签订之日启动，我们对本项目计划总体安排如下：
准备阶段 需求阶段 设计阶段 开发阶段 集成测试阶段 第1月 第2-4月 第5月 第6月 IBM银行信用卡系统建设项目
- 30 -
武汉佰钧成技术有限责任公司
7.2.1. 准备阶段
本阶段主要进行建立项目组织、建立项目管理体制、优化项目计划、工作任务定义、开发环境准备及环境搭建、招标需求分析确认等工作。
✓ 建立项目组织：我公司提出项目组织计划，与用户就本项目的项目组织
进行沟通交流，确定项目组织结构及相应人员岗位，明确项目组中每个人的责任，确定项目核心成员。
✓ 建立项目管理体制：与用户就本项目的项目管理体制进行讨论，最终形
成项目管理体制。
✓ 优化项目计划：针对实际情况对项目计划进行优化，编写项目进度计划
和预算。
✓ 招标书需求分析确认：再次确认用户在招标文件中提出的需求。 ✓ 开发环境准备及环境搭建：准备项目开发工作场所，包括软、硬件环境，
就本项目采用的各项技术，搭建开发环境。
✓ 编写项目的工作说明书，对项目实施的项目范围、项目阶段、工作方法、
相关各方的责任分工、各阶段的交付物、阶段完成里程碑、沟通制度等进行明确规定，同时编写质量保证计划，编写配置管理计划，以及项目实施的有关规章制度等；
本阶段要实现的里程碑是：签订商务合同和工作说明书。
本阶段承建方的主要参与人员有售前人员、需求分析人员、架构师、项目管理人员（含质量、配置人员）。
客户方主要参与人员为项目组织人员。 7.2.2. 需求阶段
本阶段主要内容为需求调研和需求分析，用户培训、初步用户手册的编制等工作内容。
✓ 需求调研和需求分析：公司组织资深的系统分析人员对用户需求进行进
一步的分析，与用户不断沟通、交流，确认已经明确的需求内容，经过不断调研、确认，最终形成需求规格说明书，完成由用户组织的专家进行评审。
IBM银行信用卡系统建设项目
- 31 -
武汉佰钧成技术有限责任公司
✓ 初步用户手册的编制：根据需求内容，编制初步用户手册。 ✓ 需求评审：针对需求规格说明书进行用户的需求评审。 本阶段要实现的里程碑是：签署需求规格说明书。
本阶段承建方的主要参与人员有项目管理人员、需求分析人员、架构师、开发人员。
本期客户方主要参与人员为项目组织成员、相关业务部门的部门主管及业务骨干、科技部门相关人员。 7.2.3. 设计阶段
本阶段主要内容为系统的总体设计和详细设计、数据库设计、测试方案的设计、用户培训等工作内容。
✓ 总体设计：提出设计的方法及该阶段的工作进度安排，并得到招标方确
认；编制总体设计方案；编制测试环境建设方案；编制系统上线试运行至系统正式上线期间的时间安排；提供对项目应用系统设计风险的详细评估。
✓ 详细设计：完成应用系统软件功能模块的详细设计。
✓ 数据库设计：完成数据库系统的详细设计，包括数据库结构、表结构、
数据字典等的编制。
✓ 测试方案的设计：系统详细设计，完成测试大纲、测试计划、测试用例
的详细设计，使得在下一阶段应用系统开发完成后。 ✓ 完成系统设计的评审；
本阶段要实现的里程碑是：评审通过项目设计方案（包括数据库设计方案）。 本阶段承建方的主要参与人员有项目管理人员、需求分析人员、架构师、开发人员、测试人员。
本期客户方主要参与人员为项目组织成员、科技部门相关人员、相关业务部门的业务骨干。 7.2.4. 开发阶段
本阶段主要完成应用软件系统十个模块的开发的编码与单元测试工作。包括配置研发及测试人员、配置开发及测试设备、进行系统编码、并进行测试方案的评审。
IBM银行信用卡系统建设项目
- 32 -
武汉佰钧成技术有限责任公司
本阶段要实现的里程碑是：完成软件的开发评审。
本期项目承建方主要参与人员为需求分析人员、软件架构设计人员、软件开发人员、软件测试人员、配置管理人员、项目管理人员。
本期客户方主要参与人员为项目组织成员、技术人员及相关业务部门的业务骨干。
7.2.5. 集成测试阶段
本阶段主要完成应用软件系统的集成测试工作，测试工作包括单元测试、功能测试、集成测试、性能测试、安全测试、健壮测试、界面测试、安装测试、文档测试工作，并编写相应的测试报告，同时编写系统使用手册。
本阶段要实现的里程碑是：通过系统集成测试评审。
本期项目承建方主要参与人员为需求分析人员、软件架构设计人员、软件开发人员、软件测试人员、配置管理人员、项目管理人员。
本期客户方主要参与人员为项目组织成员、技术人员及相关业务部门的业务骨干。
7.2.6. 试运行、上线及终验阶段
本阶段主要完成的工作为试运行的准备以及对在试运行过程终发现问题的修改工作，用户培训工作，数据迁移，系统过渡，试运行工作以及系统切换后的正式上线和终验工作。试运行过程发现问题，要确定工作方案，进行问题解决。
✓ 用户培训：完成此阶段对用户的培训工作。 ✓ 数据迁移：完成应用系统的数据迁移工作。 ✓ 系统过渡：完成系统过渡工作。 ✓ 试运行：完成系统试运行工作。 在完成系统上线稳定运行，进行项目终验。
本阶段要实现的里程碑是：完成系统试运行，签署系统终验报告。 本期客户方主要参与人员为项目管理人员、项目组织成员、系统集成人员、培训人员、技术人员、配置管理人员、各业务部门的领导和业务骨干人员。 7.2.7. 运营维护阶段
本阶段是从项目终验合格后开始进行为期3年的质保时间。
IBM银行信用卡系统建设项目
- 33 -
武汉佰钧成技术有限责任公司
7.2.8. 贯穿各阶段的其它任务
用户培训：此项工作从需求分析开始，到终验前结束，完成用户培训工作，培训内容包括操作人员培训、系统维护人员培训、管理人员培训。
项目管理。项目管理工作从项目启动开始，持续到项目维护期结束，主要由我公司项目管理人员完成本项目实施的管理工作。
8. 项目成果和交付物
根据项目实施的不同阶段，我公司项目组将向客户单位分批移交项目实施过程中生成的成果和各类技术文档、使用文档，结合本项目进度计划分阶段提交的成果和交付物如下表所示：
阶段名称 准备阶段 需求分析 系统设计 成果和交付物 需求规格说明书； 概要设计说明书 详细设计说明书 数据库设计说明书 系统开发 编程规范 模块开发卷宗 系统源代码及执行码 单元测试计划； 单元测试报告； 培训资料（教材）； 软件功能技术手册； 集成测试 集成测试计划； 集成测试用例； 集成测试报告（含压力测试报告）； 试运行、上线和终验 程序清单 安装维护手册 用户操作手册 程序源代码 运营维护 技术维护手册 故障应急处理手册； 备注 IBM银行信用卡系统建设项目
- 34 -
武汉佰钧成技术有限责任公司
9. 项目风险计划
9.1. 项目风险分析
尽早进行风险分析，能够减少项目实行过程中的不确定性。它不仅使各层次的项目管理者建立风险意识，重视风险问题，防范于未然，而且在各个阶段、各个方面实施有效的风险控制，形成一个前后连贯的管理过程。作为面对项目风险的有效手段，全面风险管理强调风险的事先分析与评价，风险因素分析是确定一个项目的风险范围，并将这些风险因素逐一列出以作为全面风险管理的对象。罗列风险因素通常要从多角度、多方位进行，形成对项目系统的全方位的透视，我们一般对风险因素的分析通过以下方面进行分析：
1、首先，按项目系统要素进行分析。这主要有四个方面的系统要素风险： 项目环境要素风险：最常见的有政治风险、法律风险、经济风险、自然
条件、社会风险等；
项目系统结构风险：如以项目单元为分析对象，在实施以及运行的过程
中可能遇到的技术问题，人工、材料、机械、费用消耗的增加等各种障碍和异常情况等；这是IT项目中最主要的风险。
项目的行为主体产生的风险：如承包商（分包商、供应商）技术及管理
能力不足，不能保证安全质量，无法按时交工等产生的风险；项目管理者的能力、职业道德、公正性差等产生的风险；
其他方面的风险：如外围主体（政府部门、相关单位）等产生的风险。 2、其次，按风险对目标的影响分析。这是按照项目的目标系统结构进行分析的，它体现的是风险作用的结果，它包括以下几个方面的风险：
工期风险，如造成局部的（工程活动、分项工程）或整个工程的工期延
长，不能及时投产；
费用风险，这包括财务风险、成本超支、投资追加、报价风险、收入减
少等；
质量风险，这包括工程等不能通过验收，工程试生产不合格、经过评价
工程质量未达到标准或要求；
生产能力风险，项目建成后达不到设计生产能力；
IBM银行信用卡系统建设项目
- 35 -
武汉佰钧成技术有限责任公司
市场风险，工程建成后达不到预期的经济目标，没有竞争力； 法律责任风险，可能因此被起诉或承担相关法律的或合同的责任。 3、再次，按管理的过程和要素分析。这个分析包括极其复杂的内容，但也常常是分析风险责任的主要依据，它主要包括：
高层战略风险，如指导方针战略思想可能有错误而造成项目总体目标设
计的错误等；
环境调查和预测的风险；
决策风险，如错误的选择，错误的投标决策、报价等； 项目策划风险； 技术设计风险；
计划风险，如目标的错误理解，方案错误等；
实施控制中的风险，如合同、供应、新技术新工艺、分包层、工程管理
失误等方面的风险；
运营管理的风险，如准备不足，无法正常运营，销售不畅等的影响。 从总体上可以将该项目的风险分为宏观和微观两部分，宏观方面的风险指针对该项目的特点而使项目的实施具有的风险，微观风险则指在软件开发过程中会出现的风险。基于上述分析方法，针对本项目，我们识别如下项目风险： 9.1.1. 宏观风险分析
从项目的整体规划上看，本项目作为一项IBM银行信用卡系统的一个信息化工程建设项目，其具有以下特点：
应用系统建设涉及的业务内容多； 项目工程进度时间要求短；
涉及业务学科领域广，且部分信息化建设任务缺乏案例和成功经验可
循；
由于项目的这些特点，使项目的建设存在以下风险性： 1、项目建设的统筹规划、协调实施方面的风险性
这一风险属于项目管理的风险，主要体现为制定合理的项目计划、预算项目成本、资源配置、质量管理及项目管理技术选择等方面，由于项目的建设内容多，建设内容存在交叉与关联，因此使项目的建设不确定性、复杂性并存，带来项目
IBM银行信用卡系统建设项目
- 36 -
武汉佰钧成技术有限责任公司
统筹规划、协调实施的风险性。
2、项目周期相对短造成的组织、实施方面的风险性
组织风险中的一个重要的风险就是项目决策时所确定的项目范围、时间与费用之间的矛盾。此系统的应用软件开发任务多、工作量大，而项目工期相对短，这造成了项目范围和时间的矛盾，因此给如何合理地组织人力与资源，制定可行的项目进度计划带来了困难，形成了项目实施的一定风险。
3、项目建设经验欠缺造成的实施风险性
造成这一风险的主要因素为项目涉及业务学科领域广，且部分建设内容属IBM银行信用卡系统首创，欠缺先前案例及成功经验，使系统的建设无先例可循，需在建设中摸索，从而使项目的顺利实施在进度控制、技术实现等方面存在一定风险性。
4、项目受不可控因素影响产生的风险性
该项目受不可控因素的影响主要表现在以下几个方面：
本项目的建设是一个新的业务需求，如电子登记簿的使用，复杂的监控
标准，智能监控、预警，这些都要求各级系统使用者必需在深刻理解信息化的本质基础上给予高度关注和重视，提供充分的支持。
本系统建设是一项知识密集的系统工程，项目管理不到位，缺少足够的
经验，不严格按信息化建设规律办事是等都有可能加大本项目失败的风险。
系统建设过程中如若缺乏一种有效的监督管理机制，将致使许多任务在
质量、进度、投资等方面都无法得到很好的保证和控制，出了问题就互相推诿，项目中途下马或完工后难以达到预期建设目标。 5、项目由于外部因素影响可能存在的风险性
项目外部风险主要是指项目的政治、经济环境的变化，包括与项目相关的规章或标准的变化，组织中机构的变化，如机构合并、自然灾害等。这类风险对项目的影响和项目性质的关系较大。 9.1.2. 微观风险分析
项目过程的每个阶段都存在着不同的风险，这些风险与该阶段的工作内容紧密相关。
IBM银行信用卡系统建设项目
- 37 -
武汉佰钧成技术有限责任公司
1、合同签约立项阶段可能存在的风险： 项目宏观目标不清；
项目范围不明确（范围太大太小都不可以）； 用户参与少或和用户沟通少； 对业务了解不够； 对需求了解不够； 没有进行可行性研究。 2、项目启动阶段可能存在的风险： 项目具体目标不清； 项目范围不够精确； 用户参与不够； 本项目的规划不够准确； 3、项目计划阶段可能存在的风险：
项目队伍缺乏经验，如缺乏有经验的项目经理；
没有变更控制计划，以至于变更没有依据，该变更的不变，不该变的也
变，这样得来的设计势必会失败或者偏离用户需求； 仓促计划，可能带来进度方面的风险；
漏项，由于设计人员的疏忽某个功能没有考虑进去； 4、项目执行与控制阶段可能存在的风险 设备环境没有具备好； 计划错误带来的实施困难； 项目团队实施能力差；
项目范围改变（突然要增加或修改一些功能，需要重新考虑设计）； 项目进度改变（要求提前完成任务等）；
人员离开，在一个项目内软件开发工作有一定的连续性，需要移交和交
接，有时人员离开对项目的影响会很大；
开发团队内部沟通不够，导致程序员对系统设计的理解上有偏差； 没有有效的备份方案； 没有切实可行的验收计划；
IBM银行信用卡系统建设项目
- 38 -
武汉佰钧成技术有限责任公司
验收人员经验不足； 5、收尾阶段可能存在的风险： 质量差； 客户不满意；
设备没有按时到货，软件无法应用等； 6、维护阶段可能存在风险： 系统运行不稳定； 客户人事变化；
客户业务变化导致付款出现问题；
在本项目中，上述微观风险皆在一定程度上存在，针对上述风险，我们在整体项目管理中，从组织结构、人员配备、计划管理、质量保证等诸多方面均进行了有针对性的准备，从而在一定程度上缓解上述风险，并且根据我公司的风险识别定义进行风险识别。
9.2. 主要风险识别及缓解措施
由于项目的一次性和特殊性，在风险判别中无法根据历史数据或资料对项目风险做出准确估计，只能靠专家或决策人员根据自身经验和知识对项目风险做出主观估计，特别是在项目立项论证或研制的初期阶段更是如此。为对项目风险进行准确判别，有必要规定统一的级别描述标准。我们公司对技术风险、费用风险、进度风险、管理风险进行了如下级别描述，并针对本项目进行了如下风险识别：
技术风险级别描述表
技术风险 风险本项级别 目风险 低 中等 中等 缓解措施 成熟性 复杂性 相关现有的或局部重新设计 主要部分重新设计，但技术可行 配备公司核心骨干参与项目 技术可行的复杂设计或最新技术，某些研究已完成 高 简单设计或局部增加复杂性 复杂性有中等程度增加 复杂性显著增加或极其复杂 与现有系统、设施或相关的研制单位无关或进度取决于现有的系统设施或相关的研制单位 IBM银行信用卡系统建设项目
- 39 -
低 中等 高 低 中等 通过设计原型解决 低 不需要
性 武汉佰钧成技术有限责任公司
性能取决于现有系统性能、设施或相关的研制单位 中等 进度取决于新系统的进度、设施或相关的研制单位或性能取决于新系统的性能、设施或相关的研制单位 高 费用风险级别描述表
费用风险 任务要求明确性 任务要求明确，使用方和承制方对任务有共同的理解 任务要求基本明确，某些细节上尚需进一步确定 任务要求不明确，使用方可能不断提出新的要求或双方对任务要求有不同的理解 技术风险影响 无高风险项目，中等风险项目不超过2个 风险级本项目风险 别 低 中等 高 低 缓解措施 不需要 低 低 无高风险项目，中等风险项目超过3个 中等 有1个以上的高风险项目 进度风险影响 无高风险项目，中等风险的进度指标不超过2个 无高风险项目，但中等风险项目在3个以上 有1个以上的高风险项目 成本预算准确性 有充分的类似项目的历史数据可供参考，成本估算部门有足够可用的合格人员 有足够可用的合格人员但仅有部分历史数据可供参考 缺乏可用的合格人员且无类似项目的历史数据供参考 合同类型影响 固定价格合同 成本加奖励费用合同 拨款性合同 合同报价影响 与其它竞标单位的报价和预测成本基本相符 略低于其它竞标单位报价和预测成本 报价显著低于其它竞标单位的报价和高 低 中等 高 低 低 低 中等 高 低 中等 高 低 中等 高 待定 低 IBM银行信用卡系统建设项目
- 40 -
预测成本 进度风险级别描述
武汉佰钧成技术有限责任公司
进度风险 技术风险影响 无高风险，中等风险项目不超过2个 无高风险，中等风险项目超过3个 有1个以上的高风险项目 计划安排合理性 计划切实可行且留有一定时间余度以防意外情况发生 计划可靠，但对意外发生的问题未留有余度 计划不可靠，不是根据每项研制工作的实际需要来安排时间，而是根据竞争的需要或上级命令来分配时间 资源充分性 资源充足且可供使用 现有资源充足，但与其它项目之间有潜在的矛盾冲突，可能因某些预想不到的问题而影响进度 现有资源不足或与其它项目之间存在严重的潜在冲突 项目人员经验 参与该项目的人员在类似的项目中已积累了经验，有足够的知识储备可用于该项目 参与人员在类似的项目中已有一般性的经验，但在某些关键部门还缺乏有经验的人员 参与人员普遍没有在类似项目中工作的经验，关键部门可用的有经验人员很少 管理风险级别描述
风险级本项目缓解措别 风险 施 低 中等 高 低 中等 高 中等 通过集中封闭开发和对进度加强控制，根据情况增加资源等来缓解 不需要 低 不需要 低 中等 低 高 低 低 不需要 中等 高 管理风险 领导素质影响 领导者决策能力强，很有威望 领导者决策能力较强，威望一般 领导者决策能力一般，同时也没什么威望 风险级本项目风险 别 低 中等 高 低 缓解措施 不需要 IBM银行信用卡系统建设项目
- 41 -
组织机构影响 武汉佰钧成技术有限责任公司
组织机构健全，各机构间配合密切、融洽，运作效率高 组织机构基本完善，运作效率一般 组织机构不完善，或虽完善但运作效率很低 低 中等 高 低 中等 高 低 中等 高 低 中等 高 低 中等 低 计划条理性 计划安排很有条理，且在关键项目上态度较为保守 计划安排有序，但在计划安排上态度较激进 计划安排没条理，或一般但态度很激进（冒险型） 低 研发人员素质 研发人员整体素质高，且人员之间协作能力强 研发人员整体素质较高，但人员之间协作能力一般 人员整体素质一般，协作能力也一般 低 研发实力及条件 实力雄厚、条件优越且得到大家一致公认 实力和条件较好，能胜任项目的研究 实力和条件一般，基本能胜任项目研究工作 低 各阶段的协调 协调能力强，能作好各阶段的协调工作，应付突发事件能力强 协调能力较强，正常情况下能保证各阶段的协调一致，应付突发事件的能力一般 低 协调能力一般，应付突发事件的能力差 高 9.3. 其他风险控制措施
1、风险分配
项目风险必须在项目参加者（包括投资者、业主、项目管理者、承包商、供应商等）之间进行合理的分配，只有每个参加者都有一定的风险责任，才有可能对项目管理和控制的积极性和创造性，只有合理的分配风险才能调动各方面的积极性，才能有项目的高效益。合理分配风险要依照以下几个原则进行：
从工程整体效益的角度出发，最大限度地发挥各方面的积极性。
项目参与各方如果都不承担任何风险，则他也就没有任何责任，当然也就没
IBM银行信用卡系统建设项目
- 42 -
武汉佰钧成技术有限责任公司
有控制的积极性，就不可能搞好工作。因此只有让各方承担相应的风险责任，通过风险的分配以加强责任心和积极性，达到能更好地计划与控制。其有效的做法应为合同管理的机制到位，并面向各个承包商和参与方的工程合同，应站在工程总体的高度上进行控制和实施，公平合理，责、权、利平衡。
一是风险的责任和权力应是平衡的。有承担风险的责任，也要给承担者以控制和处理的权力，但如果已有某些权力，则同样也要承担相应的风险责任；二是风险与机会尽可能对等，对于风险的承担者应该同时享受风险控制获得的收益和机会收益，也只有这样才能使参与者勇于去承担风险；三是承担的可能性和合理性，承担者应该拥有预测、计划、控制的条件和可能性，有迅速采取控制风险措施的时间、信息等条件，只有这样，参与者才能理性地承担风险。
2、风险对策
任何项目都存在不同的风险，风险的承担者应对不同的风险有着不同的准备和对策，这应把它列入计划中的一部分，只有在项目的运营过程中，对产生的不同风险采取相应的风险对策，才能进行良好的风险控制，尽可能地减小风险可能产生的危害，以确保效益。
通常的风险对策为：
采取先进的技术措施和完善的组织措施，以减小风险产生的可能性和可能产生的影响。如选择有弹性的、抗风险能力强的技术方案，进行预先的技术模拟试验，采用可靠的保护和安全措施。对管理的项目选派得力的技术和管理人员，采取有效的管理组织形式，并在实施的过程中实行严密的控制，加强计划工作，抓紧阶段控制和中间决策等。
3、实施中的全面风险控制
工程实施中的风险控制贯穿于项目控制（进度、成本、质量、合同控制等）的全过程中，是项目控制中不可或缺的重要环节，也影响项目实施的最终结果。
加强风险的预控和预警工作。在工程的实施过程中，要不断地收集和分析各种信息和动态，捕捉风险的前奏信号，以便更好地准备和采取有效的风险对策，以抗可能发生的风险。
在风险发生时，及时采取措施以控制风险的影响，这是降低损失，防范风险的有效办法。
IBM银行信用卡系统建设项目
- 43 -
武汉佰钧成技术有限责任公司
在风险状态下，依然必须保证工程的顺利实施，如迅速恢复生产，按原计划保证完成预定的目标，防止工程中断和成本超支，唯有如此才能有机会对已发生和还可能发生的风险进行良好的控制，并争取获得风险的赔偿，如向保险单位、风险责任者提出索赔，以尽可能地减少风险的损失。
10. 项目测试与验收方案
10.1. 项目测试方案
10.1.1. 测试概述
软件工程的测试是非常重要的一环，也是检验系统开发最终目标能否完全达到设计要求的重要环节，同时系统测试环节也是系统开发过程中的\"软肋\"。一般情况下，业界对开发人员的投入比例偏大，而不太重视测试，这也是导致很多国内软件品质不稳定的原因。我公司对测试工作非常重视，测试过程严格按照公司质量体系标准《软件测试控制程序》执行。测试方法除采用传统的测试方式外，还采用了先进的测试工具辅助测试。
系统安装完成后，首先拟出一个测试方案，详细确认每个测试环节的测试用例，并与业主讨论通过后，按计划进行测试。对系统每一项测试有详细的测试记录，同时用户方、投标人代表签字确认，并附有详细的分析报告。 10.1.2. 测试目标和原则 10.1.2.1. 测试目标
测试过程是验证建设成的最终系统是否满足原始需求并且遵循系统设计，测试的目标是尽可能多的发现系统中存在的错误，并能发现及预言潜在的错误，以保证系统正常运行。测试的最终目的则是发现应用软件的错误，达到在硬件和系统软件支撑下，应用软件系统能正常、稳定、可靠运行的目的。 10.1.2.2. 测试原则
制定规范和完整的测试计划，严格按计划组织测试，排除测试活动的随
意性。
预先组织和准备好各种测试用例和测试数据，以保证测试活动的顺利开
IBM银行信用卡系统建设项目
- 44 -
武汉佰钧成技术有限责任公司
展。
测试输入数据应与对应的预期输出结果配套。
测试用例中不仅有合理的输入条件，还要有不合理的输入条件。 妥善保存各种测试文档及测试用例与数据，为以后软件重测和维护提供
方便。
对每一个测试结果要做全面的分析和检查。
系统测试过程中发现的所有缺陷用统一的缺陷管理工具来管理，开发人
员根据缺陷管理报告及时改正错误。
10.1.3. 测试组织
针对本项目实施特点，我公司成立专门的测试组织来完成测试工作，测试的组织结构是属于项目组，但是独立于开发组，测试经理的直接汇报渠道是项目经理。其角色和职责分别定义如下：
测试组织角色和职责定义
角色 项目经理 测试经理 职责 全面领导，对测试项目进行监督、管理，对重大问题进行决策。 测试中的主要角色，测试中所有环节的组织者，和主要实施者； 负责制定《测试策略》和《测试计划》； 负责单元测试、集成测试、系统测试活动的组织安排； 确保所有测试活动按照计划进行，确保测试记录得到维护，并根据测试工具的有效应用产生测试度量数据； 负责《测试分析报告》。 备注 需求经理 测试工程师 架构师 负责测试用例的分析和设计； 负责开发业务方面的测试用例。 在测试经理的组织下，负责测试的设计、测试用例的开发和测试执行工作。 负责性能测试用例的开发和执行； 负责性能测试指标的定义和结果分析； 协助开发组定位性能瓶颈和确定优化应用系统。 质量管理人员 协助测试经理完成测试过程中的质量管理； 10.1.4. 测试内容
本项目的测试种类包括：单元测试、集成测试、功能测试、界面测试、健壮测试、安全测试、性能测试、安装测试、文档测试等。
IBM银行信用卡系统建设项目
- 45 -
武汉佰钧成技术有限责任公司
在进行测试前，需要编写详实的测试方案，其中包括测试时间安排、测试准则、测试用例、测试范围、测试目标、测试人员、出错处理流程及处理结果等内容。在测试案例中应包含对异常情况处理的测试，如数据不全、数据类别有误、数据不合法等。
各种类型的测试都是采用循环往复的“测试－改进”操作，以确保问题得到完整、充分的解决的过程。
1、单元测试：
单元测试也称为模块测试，是针对每个模块进行的测试，测试软件独立单元在与其它程序隔离的情况下的应用。每个应用程序模块完成后，进行模块测试。模块测试的目的在于通过大量、反复的测试，尽可能地捕获程序编写时的编码及应用处理上的错误，并加以改正，使程序编写时的错误在这一测试环节得到控制。
单元测试采用白盒法，测试是基于程序设计的逻辑结构和对象方法。 2、功能测试
功能测试是对项目实现的功能进行测试，是在规定的一段时间内运行软件系统的所有功能，以验证这个软件系统没有严重错误。功能测试基于黑盒技术，通过用户界面与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程（包括程序单元、模块、整系统）。功能测试可细分为：独立测试和连续测试两部分。
独立测试是将本项目开发实现的功能一一进行独立测试。在测试过程中，将针对每一个功能制定相应的测试个案，进行严格的功能测试。如测试结果与实现要求不符，将由开发人员进行改进及完善，最终达到功能要求。
测试中发生问题时，编程人员会改动程序以便解决问题。系统将在修改后进行重新测试。此时其进行的测试不仅针对改动部分，还应对原已通过独立测试的部分进行重新测试。
3、集成测试
集成测试的目的是集成各单元模块验证系统功能是否满足需求。
集成测试检测系统是否达到需求对业务流程及数据流的处理是否符合标准，系统对业务流处理是否存在逻辑不严谨及错误，需求是否存在不合理的标准及要求。
IBM银行信用卡系统建设项目
- 46 -
武汉佰钧成技术有限责任公司
集成测试分为增量集成测试、非增量集成测试，增量集成测试是在单元测试之后，采用自顶向下或自底向上逐层安装测试。非增量集成测试是将单元测试后的模块按照总体的结构图一次性集成起来，然后把连接的整体程序测试。
集成测试包括黑盒和白盒测试。针对不同的集成接口来开发不同类型的集成测试用例，测试的方法的选择根据概要设计对于集成模块和系统的不同定义来分析。
集成测试的步骤包括：
在概要设计完成后，测试组编写《集成测试计划》；
在开发组进行详细设计和代码编写阶段，测试组分析被测系统的集成方
案，开发集成测试用例，准备集成测试数据；
在编码基线后，单元测试完成后，测试组在测试工具中执行集成测试用
例，通过测试工具填写发现的缺陷；
测试经理在集成测试阶段完成后提交《集成测试分析报告》。 4、界面测试
界面测试实现对软件系统的易用性和视觉效果等的测试。用于核实用户与系统之间的交互。确保界面中的对象按照预期的方式运行，并符合所有的标准。
5、健壮测试
健壮测试是测试应用系统在异常情况下能否正常运行的能力。在设计和编码阶段编写相应的测试用例，在系统开发完成后对单个子系统和集成后的子系统进行健壮性测试，以验证系统在异常情况下的错误处理能力，对发现的错误在BUG库中进行记录，描述故障现象，组织设计人员、开发人员、集成人员对错误进行诊断，并排除错误。
6、安全测试
安全测试测试内审综合系统防止非法入侵的能力。检验系统安全性方面有无漏洞。安全性测试侧重于应用程序级别的安全性和系统级别的安全性两个关键方面：
应用程序级别的安全性，包括对数据或业务功能的访问；系统级别的安全性，包括对系统的登录或远程访问。
应用程序级别的安全性可确保：在预期的安全性情况下，参与者只能访问特
IBM银行信用卡系统建设项目
- 47 -
武汉佰钧成技术有限责任公司
定的功能或用例，或者只能访问有限的数据。例如，可能会允许所有人输入数据，创建新帐户，但只有管理员才能删除这些数据或帐户。如果具有数据级别的安全性，测试就可确保“用户一”能够看到所有客户消息，而“用户二”看见同一客户的统计数据。
系统级别的安全性可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问。
7、性能测试
性能测试着重于测试金融服务平台二期项目并发数及相应效率。对目标系统来说，系统的性能是一个很重要的参数，在测试中，为每个应用设置响应时间、处理速度量度，评估系统的最高处理能力，在发现系统的性能不满足要求进，需进行相应措施对系统的性能进行调整。
8、安装测试
安装测试测试金融服务平台二期项目安装与反安装。安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下，例如，进行首次安装、升级、完整的或自定义的安装，都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。
测试内容包括但不限于：
手工开发脚本或开发自动脚本，以验证目标计算机的状况； 启动或执行安装；
使用预先确定的功能测试脚本子集来运行事务。 9、文档测试
文档测试对用户所有文档进行详细测试，检查文档的完整性、正确性、一致性等。
文档测试范围包括本项目所有要提交的文档，在项目实施的需求、设计阶段定义项目文档种类、规范标准，在各个开发阶段评审时就进行文档测试，在项目终验时对全部项目文档按完整性、正确性、一致性标准进行详细测试，确保文档的质量。 10.1.5. 测试步骤
根据本项目实施进度要求安排测试步骤如下：
IBM银行信用卡系统建设项目
- 48 -
武汉佰钧成技术有限责任公司
1、制定测试计划：明确时间、人员安排，系统测试时间；特别注意阶段性完整测试版本的计划安排。确定测试重点（测试设计）并对测试计划进行版本管理。
2、准备测试环境：根据项目环境、计划要求，测试员在测试服务器搭建测试环境
3、准备测试数据：根据项目开发计划的时间安排，编写测试用例 4、获得测试版本：
首先，测试版本可分为两种：增量测试版本、完整测试版本。在系统完善修改的测试阶段，可以采取增量式测试，即只对增加的修改内容进行测试；在计划的时间点取得完整的测试版本（执行包括数据重新初始化在内的操作），对版本进行全面的回归测试，并且必须保证所有情况下实施前的最后一个版本进行过完整测试。
增量式测试，可由开发方和测试方协同作业，使用共同的程序、数据库环境进行测试；
完整测试，根据测试计划安排，开发方通知测试方可以进行完整版本测试，测试组从配置库中取得完整版本测试版本（包括程序文件、数据库执行文件、配置说明文件等），测试组执行安装过程，将测试环境搭建起来。
如满足终止测试的条件，则终止测试，通知开发组重新组织测试版本。 5、执行测试：测试员执行测试用例，将问题记录于bug管理工具，bug记录要尽可能详细的填写测试用例执行过程。
在执行测试用例进行测试时，如果需要调整测试用例或测试方法，修改测试计划与测试用例，并在修改历史中记录修改原因与修改办法。
6、编制测试报告：按照测试计划，项目版本达到测试通过标准，测试方撰写《测试报告》。《测试报告》通过内部审核后，项目发行版本可发行，项目测试工作可结束。
7、测试总结：根据项目的计划安排，项目测试结束后，测试人员对测试过程进行总结。对测试过程进行总结分析，在项目总结会议上提交，共同讨论，汇总经验。总结内容可在项目总结中以任何形成进行体现。
IBM银行信用卡系统建设项目
- 49 -
武汉佰钧成技术有限责任公司
10.1.6. 测试过程进度及质量控制
有了测试计划和规范，只是知道做什么和如何去做，但是有没有按要求去做，做得好不好，就必须在测试过程中进行进度控制和质量控制。需要及时的进行落实，还要实时的进行跟踪测试的执行情况、发现问题，并及时调整测试策略，以使测试过程中的质量和进度得到保证。
进度控制主要是看能不能按照测试计划的工作任务和时间要求完成。这就需要随时掌握测试工作的进展情况，若进度拖延，要考虑是在合理的时间范围内调整以后的测试计划，还是必须加快以后的工作效率赶上计划的进度。在子系统确认测试执行过程中，我们采取了每天填写《测试过程记录表》的方式了解每天测试执行工作的进展情况，来进行进度控制。
测试质量的控制主要是对测试需求、用例设计、测试方案的评审。评审主要包括：
全面性——测试需求是否覆盖所有业务功能、测试用例是否覆盖所有的
测试需求；
正确性——测试需求抽取、用例设计、方案设计的正确性； 可操作性——用例及方案是否便于实施和操作。
10.2. 验收方案
10.2.1. 概述
项目验收的目的是保证项目质量，使系统在计划的进度内上线试运行和投入使用。本项目验收包括项目实施过程中各阶段的验收，包括需求分析、总体设计、详细设计、编程开发、集成测试、系统集成、终验等主要阶段的验收。验收过程工作主要包括组织、安排项目各阶段的验收会议，提交各阶段验收文档，由人行项目领导小组进行评审。 10.2.2. 验收标准 10.2.2.1. 验收方案的原则
完整一致性，最终验收要求与项目前期与用户确认的《需求规格说明书》
和本期项目的需求文档相一致，业务功能实现跟要求相比没有遗漏； 正确性，系统实现的功能是在理解正确的基础上实现了客户的要求。软
IBM银行信用卡系统建设项目
- 50 -
武汉佰钧成技术有限责任公司
件系统的功能正确、稳定；
可操作性，验收要求及测试手段在现有人力、工具和技术条件下能够实
现，从资源、时间、成本来看是可操作的；
验收方案在生产环境或者接近生产环境下，系统在未来的实际运行情况
能够在验收和测试环节中充分体现。
验收和测试涉及单位包括：甲方、开发商以及其他人员。 10.2.2.2. 系统验收标准
系统的验收标准将依照人民银行有关信息系统建设的规范，从系统的实用性、稳定性、可维护性、灵活性、可操作性及系统文档、代码、规范及注释说明，双方签署的《需求规格说明书》和双方签订的合同书等方面进行本项目的验收。
我公司根据招标文件提出验收方案和验收文档清单（包含需求分析、系统设计、系统开发、集成测试、系统初验、试运行、总体验收等阶段），供招标方根据验收方案对系统每个部分进行逐一进行项目用户验收。
验收时，我公司遵照招标方具体要求进行验收。项目的最终验收由人民银行组织和协调。
本系统是一个复杂的业务服务和数据处理系统，因此对于验收的标准具体包括如下几个部分来分别阐述，有对系统业务功能的验收标准、系统性能的验收标准、对交付物文档的验收标准、源程序验收标准以及对在验收测试中发现的缺陷的处理等。
系统业务功能验收
1、系统完全符合用户方和佰钧成双方确认的《软件需求规格说明书》（以双方签字为准）所定义的功能要求以及软件委托开发合同为依据。
2、确认系统实现的业务功能完备、正确、满足客户的需求。 软件过程文档验收标准
1、文档验收以抽样方式进行，抽样率为20%左右； 2、文档内容验收标准：
文档内容真实、丰富，能清楚阐述实施内容；如果在验收的文档中，错误的总字数超过抽样文档总字数的0.5%，或描述每一独立完整的功能/章节错误，则视为验收失败；否则为验收合格；
IBM银行信用卡系统建设项目
- 51 -
武汉佰钧成技术有限责任公司
3、文档格式验收标准：
文档格式与项目实施要求文档规范相符，文档具有详细的修改记录，版权、作者、时间等信息，包括完整的页眉、页脚等信息；
4、文档一致性验收：
需求文档、设计文档、源程序与目标码保持一致。 源程序验收标准
1、源程序经过编译、部署、试运行正常后，即为验收合格；
2、源程序中有明晰的注释，符合IBM OS/400的规范和客户要求的编码规范； 3、源程序和目标代码保持一致，无冗余代码文件；
4、源代码目录部署合理，参数文件或配置文件齐全，存放路径合理。 验收测试的缺陷处理
1、如果验收测试后，系统的遗留缺陷按照严重程度分类，分别满足对应的验收标准则视为验收测试合格。
2、对于在验收测试中遗留缺陷达不到验收标准的规定，视为验收初步不通过，双方共同商定遗留缺陷的修改计划，开发商承诺在规定的时间内解决遗留问题，双方可以商定验收测试是否合格。在遗留问题解决后，客户再次验证承诺解决的问题。
3、对于在验收测试中发现的缺陷，必须专门跟踪并报告解决状态和跟踪记录。
10.2.2.3. 问题级别定义
问题类别 A级 B级 C级 D级 问题名称 致命错误 严重错误 一般错误 微小错误 问题描述 可能导致本模块以及其他相关模块异常，死机等问题。 问题局限在本模块，导致模块功能失效或异常退出。 模块功能部分失效，影响部分功能的正常运行。 软件存在错误，但不影响业务的运行。比如提示性问题、UI问题、操作习惯等，由问题提出人对测试对象的改进意见。 建议修改问题，例如界面美化问题等。 E级 建议 10.2.2.4. 测试通过标准定义
测试类型 A级问题 B级问题 C级问题 D级问题 IBM银行信用卡系统建设项目
- 52 -
单元测试 无 武汉佰钧成技术有限责任公司
存在，但问题只局限与本模块之中，问题的出现只是导致本模块部分功能失效，并且功能性错误的个数不超过同类错误的5%。 存在，但发生问题的模块与其他模块耦合性很小，或发生问题的模块为外围模块，可通过手工设置参量的方法暂时解决问题，对其他模块测试影响小，且问题个数不超过同类错误的5%。 缺陷数<20 存在，只是部分功能失效，可在短期内解决，且问题个数不超过同类错误的10%。 对于解决起来有困难的问题可暂不解决，但要承诺解决时间。 集成测试和系统测试 无 存在，只是部分功能失效，不影响其他模块，且问题个数不超过同类错误的10%,并承诺解决时。 不存在二义性，或操作过于复杂，用户无法按操作说明完成操作的问题。 验收标准 缺陷数＝0 并在2个工作日内修复。 缺陷数<50 并在10个工作日内修复 10.2.2.5. 测试异常的定义
对在测试过程中因为系统、环境、网络、应用等问题，导致测试不能正常进行。在测试异常发生时，开发组优先解决引起导致该异常发生的缺陷和BUG，如系统宕机、测试BUILD不能安装启动、发生致命问题的BUG等。
对于在验收测试过程中发生的因为应用导致的测试异常，导致验收测试过程中止，验收测试不能通过。必须在异常解决后再进行验收测试。直至验收测试通过。
10.2.3. 验收流程
项目组在完成系统正式上线后，验收前两周提交所规定的交付物，并提出验收申请。佰钧成组织用户方按验收标准所规定标准对项目交付物（软件、文档、源程序等）进行验收。
若未通过验收，针对不合格的部分，项目组负责改正，并对改正部分再次提出复验申请，佰钧成必须组织用户方在收到复验申请的15个工作日内进行复验，
IBM银行信用卡系统建设项目
- 53 -
武汉佰钧成技术有限责任公司
若在此期限内佰钧成与用户方客户方未提出复验意见，则视为验收通过。
对同一交付物验收如果不通过达到三次，则视为验收未通过。客户不再接受验收申请。 10.2.4. 验收方式
因为该项目业务复杂，因此项目的验收工作分为需求分析、系统设计、开发测试、系统初验、整体验收五个阶段，以减少项目实施的风险。
需求、设计、开发阶段的验收：包括需求分析、系统设计、开发测试三个阶段的验收评审，在投标人完成系统相应阶段工作，并准备好相关文档后，提前两天向招标方提交阶段验收申请，由招标方组织相关人员进行验收评审，如果发现问题，由实施方补充完善后再次进行评审验收。
系统初验：初验阶段包括安装调试、系统联调等内容，系统初验也包括这些方面的内容。在系统安装调试并联调完成后对系统进行初验，包括对系统主要技术、指标、系统功能、使用范围、文档的完整性等进行初步检验。实施方提出书面申请，采购人审核后，组织有关部门和人员对系统必须达到规定的功能、性能、使用等方面的要求进行初步验证。初验的目的是为系统的试运行创造条件。
整体验收：在总体验收之前，必须经过试运行并达到目标，新系统运行稳定并达到用户目标。实施方提出书面验收申请，总体验收由人行武汉营管部主持，组织有关领导、专家、相关主管部门和投标人组成验收组，对本系统工程进行全面最终的质量验收。
1、验收前两天，实施方应该将报告及有关资料报采购人。
2、验收内容包括：对本系统工程进行全面校验，评定工程质量；进行文件资料和软件系统的移交工作，提交验收报告；签发验收证书。
3、验收中如发现有问题，由验收组按实际情况分清责任，责成实施方解决，并暂停验收，待实施方处理完毕后，再进行验收。 10.2.5. 验收内容 10.2.5.1. 软件系统
软件主要根据双方签署的《软件需求规格说明书》的要求和合同的要求，根据《验收测试大纲》和《验收测试计划》检查已经实现的软件的功能有无缺漏、
IBM银行信用卡系统建设项目
- 54 -
武汉佰钧成技术有限责任公司
功能是否正常、是否满足《软件需求规格说明书》中的定义和要求。
软件是否通过了软件的单元测试、集成测试、功能测试、界面测试、健壮测试、安全测试、性能测试、安装测试、文档测试。
软件的性能是否符合《软件需求规格说明书》中定义的非功能性需求的要求，性能测试分析报告中的测试结果是否跟实际情况一致。 10.2.5.2. 过程文档
项目中需要提交给客户的所有文档资料和为本期工程开发的软件源代码和可执行代码。
需要提供的资料参见交付成果的内容。
11. 项目实施制度和规范
11.1. 实施制度
对于评论网站建设项目，由于参与人员多、内容复杂，项目的实施必须建立相应的制度规范，使项目参与各方对自己的工作做到有章可循，达到方便管理和沟通的目的。
为加强项目组织成员之间的沟通，实现思想、技术共享，保证本项目的顺利开发，项目组将制定以下规章管理制度。 11.1.1. 决策制度
决策制度是对合同中没有涉及、或者有冲突的职责和权利进行决策的制度。决策内容包括各个方面，但是制定以下几个原则：
1、项目经理首先决策原则
对于不大的决定，一般由项目经理加以决策，然后提交给项目领导小组，一般在一周之内，如果没有任何一方提出异议，则该决定生效，此异议应以书面方式表达。
2、最高权力机构准则
项目领导小组可以推翻项目经理和任何项目机构的决策。 项目经理可以推翻各个执行小组成员的决策。 3、发起决策原则
一切决策应有书面文件，并且在项目领导小组双方代表处备案。
IBM银行信用卡系统建设项目
- 55 -
武汉佰钧成技术有限责任公司
4、自主发起决策原则
一切需决策的问题，如果无章程可循，首先遇到此问题的项目成员，需拿出自己的建议，并且提交项目经理，如果项目经理在获得建议后三个工作日内没有口头或书面异议，则该决定生效。 11.1.2. 沟通汇报制度
1、周例会
由项目经理组织在现场的双方项目组成员参加周例会。总结上周工作，形成项目周报。项目周报的内容包括：上周工作进展报告、本周工作计划、本周任务分派报告。
与会人员分别介绍上周计划的工作内容，实际完成的工作内容。如果出现进度延迟，项目小组长和具体开发人员要对进度延迟进行分析，提出弥补方法。周例会的目的是通过交流沟通，使项目组所有成员都了解其他项目组成员的工作内容及实现方式，为后续项目人员调整做储备。
2、阶段例会
每个阶段完成时，项目经理将组织参建单位主要负责人召开项目例会，总结这个阶段工作情况形成阶段工作总结。并发送项目各个成员及双方领导。 11.1.3. 需求管理制度
需求指明了系统开发所要做和必须做的每一件事，指明了所有设计应该提供的功能和必然受到的制约。需求管理的过程，从需求获取开始贯于整个项目生命周期，力图实现最终产品同需求的最佳结合。
需求管理是完整管理模式中的一环，同其他特性诸如完整性、一致性等不可分割，彼此相关而成一体。需求管理应保证一套需求是已知系统需求的完整体现，每部分解决方案都是对总体需求一定比例的满足，仅仅解决部分需求是没有意义的。
具体的需求开发过程包括：需求获取、需求分析、编写需求规格说明书、需求验证几大步骤。需求管理必须保证需求开发过程和产出物的质量，以及随后的系统开发活动（包括设计、编码、测试、维护等）正确、完整、一致地实现已定义的需求。需求管理主要涉及需求评审、需求确认、需求跟踪、需求变更控制等几方面的工作。
IBM银行信用卡系统建设项目
- 56 -
武汉佰钧成技术有限责任公司
11.1.4. 变更管理制度
变更管理是软件项目的重要内容，无休止、随意的变更将严重影响产品的质量，带来更多的问题。变更管理一定要确定基线的概念，所谓基线就是经过评审、审批、测试后形成的工作产品。对基线的变更必须严格管理、严格受控。变更管理包括需求变更、设计变更、测试变更等环节。针对不同的特点应由不同人员来加以控制。
需求变更原则上由需求人员提出，业务负责人审批，重大变更必须由需
求开发负责人和项目经理审批；
设计变更原则上由业务人员和开发人员和相关人员提出，项目经理审
批；
内部测试变更原则上由测试人员提出，项目组内的项目经理或技术经理
负责；
验收测试、试运行等测试问题由最终用户提出，经过业务负责人汇总审
批后，实施组执行。
11.1.5. 配置管理制度
配置管理的作用是建立和维护在整个软件生命周期中项目产品的完整性、一致性和可追踪性。它关注的不是软件的好坏，而是工件的有无。
良好的配置管理是变更控制的基础，它提供了配置项存储、版本管理、一致性控制、访问控制、工作区管理、备份及恢复等强有力的功能。
建议整个工程设置一个配置管理系统，所有的项目文档和交付物纳入配置库进行管理。这样便于统一进行配置管理，变更控制，防止不必要的变更给工程带来影响。
配置管理的主要活动有：编制、评审和批准SCM计划；SCM人力组织；建立配置环境；发布配置状态报告；基线发布；变更申请、审核与实施；发送变更结果给受影响方；配置审计；产品发布等。 11.1.6. 问题管理制度
所谓问题就是那些必须采取行动去解决或纠正，否则可能对交付日期，预算或是交付成果的质量有负面影响的问题或是不确定性。 典型的问题如：
项目范围的变更
IBM银行信用卡系统建设项目
- 57 -
武汉佰钧成技术有限责任公司
项目交付成果发生了变化 交付成果未达到规范定义的要求 缺乏有经验的项目人员 项目进度的推迟或是超过预算
问题管理就是通过识别、分析、解决、报告等手段，帮助工程和各个项
目及时解决发生的问题，并与相关团队/部门进行必要的沟通。 早期识别问题，最小化问题对项目造成的影响 分析问题并执行合适的方法/手段解决问题 确保问题和问题的解决能得到连续的监控和评估 11.1.7. 文档管理制度
在项目实施过程中，由于项目实施的复杂性，双方人员参加以及时间跨度长等因素，所以有关需求、建议、解决方案和结论都必须文档化、标准化，以便查阅和引用。实施文档应作为项目成果的一个组成部分。收集的项目文档至少应包括：
项目管理文档 客户提交的需求文档
实施开发方提交并由客户确认的解决方案文档 客户需求改变报告和批准书 开发文档
测试方案和测试结果报告 客户签署的阶段成果确认书 项目总结报告等 文档管理内容主要包括： 文档的命名标准 文档的版本控制 文档的批准和存档 命名标准
文档按照：模块名-文档性质-日期命名
IBM银行信用卡系统建设项目
- 58 -
武汉佰钧成技术有限责任公司
报告签收记录
对于双方提交的需要对方进行签字确认的报告或文档，在5个工作日内应签字批准，或者书面形式做出有保留意见的批准或拒绝。在双方提交和签字后应填写“报告签收记录”。
版本管理
所有的文档必须采用统一的版本标准，以便于质量审计和文档的验收工作。当文档最终确定后，统一提交项目经理存档，若需要修改的须通过变更流程。
11.2. 实施规范
11.2.1. 质量管理规范
1、质量计划
我公司承诺通过不断改善和吸收新技术及新的管理观念，以高素质、具备专业知识的员工来提供技术支持服务，确保项目按时交付，满足客户的要求。我公司总目标为：确保客户满意度，实行项目全要素管理，项目经理负责制，保证项目在整个的执行过程中均能按照既定的模型顺利完成。
质量计划的编制的依据主要包括如下几个方面： 1、质量方针： 2、范围说明 3、产品描述 4、标准和规则 5、其他过程输入 其中：
质量方针：在公司大的质量方针的基础上，针对每个项目的特点及需求，我公司为每个项目都确立了该项目质量目标，列入项目质量计划，要求所有项目的参与者清楚地明白最终执行结果所需要达到的标准是什么。
范围说明：明确项目的各项内容和执行结果，确保参与项目的各个小组明确各自的责任和范围分工，保证各个小组之间的接口平滑、流畅，使项目能按计划顺利完成，并作为项目决策的文档基础。
产品描述：在产品描述中包含了可能影响到质量计划编制的所有技术要点和
IBM银行信用卡系统建设项目
- 59 -
武汉佰钧成技术有限责任公司
其他需注意事项的详细内容。
标准和规则：包括所有项目在执行过程中可能涉及到的标准和规范。即包括技术标准和规范，同时也包括了工作规范。
其他过程输入：除了范围说明和产品说明，我公司的质量计划在编制的过程中也包含了其他应用领域的过程中可能影响项目的标准和规则。
综上所述，我公司的质量管理规范的第一环就是确定完善而科学的质量计划，这就保证了我公司尽早发现并解决将所有可能产生的质量问题，而非集中在项目实施过程中去作更改。
2、质量审计
在项目的进行中，由技术专家顾问，项目管理部和质量控制人员组成专门的质量控制小组，不定时的对项目在技术和管理方面进行抽查，并将考核直接上报给公司的最高管理层，统筹管理，保证了项目能高标准的满足用户需求。 11.2.2. 分析设计规范 11.2.2.1. 系统分析规范
系统设计人员首先对系统需求进行分析，准确地理解和把握客户的目标和实际需求，以利于系统设计人员根据系统需求和目标进行系统设计。
分析系统需求的主要关注点
当前环境情况和系统需求。当前环境可以从网络环境、应用环境、客户运行环境及其他特殊需求几方面分析。
保证系统实施要解决的主要问题，列出最突出、最紧迫的问题，争取客户方的合作，在系统开始实施前即加以解决。
实施系统过程中使用的核心技术和方案的总体思路。 系统分析初步明确的内容
系统目标：系统目标的主要功能描述和运作方式。
系统设计原则：明确系统设计时遵循的基本理论或基本原则，例如面向对象的系统分析原则、逐步求精原则等。
系统结构：当前系统的逻辑及物理结构，正在运行的软件及其配置图。 数据库结构：描述核心数据的结构，确定数据的访问方式与范围。 网络环境：当前系统的网络拓扑结构图，目标系统的网络结构图，以及网络
IBM银行信用卡系统建设项目
- 60 -
武汉佰钧成技术有限责任公司
上采用的工业标准如通讯协议、命名规则等。
安全性要求：系统当前使用的安全管理方式，以及为适应新系统要求应做出哪些安全管理方面的改进。
性能要求：由子系统性能受很多因素的影响，故先按系统性能要求把业务流程分解，针对分解的每方面确定性能要求，充分考虑制约性能的不利因素，以及保证性能要求的技术手段。 11.2.2.2. 概要设计规范
系统分析完成后，就可以着手系统概要设计了。概要设计一般被称为总体设计。有时和系统分析结合在一起进行。
系统目标和原则
系统目标：明确本次设计需要明确的目标。
系统设计原则：明确系统设计时遵循的基本理论或基本原则，例如面向对象的系统分析原则、逐步求精原则等。
方案选择
根据系统分析结果考虑几种可能的解决方案。通常从成本方面考虑，有以下几类可能的方案：
低成本解决方案：系统只考虑完成最必要的工作，不多做额外工作。 中等成本解决方案：系统不仅能够很好地完成预定的任务，而且还具有用户没有具体指定的某些功能和特点。虽然用户没有提出这些具体要求，但设计者根据自己的知识和经验断定，这些附加的功能在实践中将证明很有价值。
高成本完美解决方案：具有用户可能希望具有的所有功能和特点。 项目经理应该使用系统流程图或其他工具描述每种可能的系统，估计每种方案的成本和效益，还应该在充分权衡各种方案的利弊的基础上，推荐一个较好的系统（最佳方案），从中选择适合系统的方案和解决问题的策略。
结构设计
进行系统总体结构设计，结构设计的一条基本原理就是系统模块化，也就是将一个大系统分解成许多规模适中的模块，按合理的结构（层次体系结构或客户机/服务器结构）组织起来，确定程序由哪些模块组成以及模块间的关系。
明确各个模块的概要设计。
IBM银行信用卡系统建设项目
- 61 -
武汉佰钧成技术有限责任公司
明确各个模块的内部概要设计，包括模块内部的子模块划分、模块功能等。 一般用图形的方式进行表现。 其他设计
进行总体设计时，需要明确数据流程设计、数据库设计、数据结构和算法设计、界面设计、安全性设计、接口设计等。
数据流程设计：明确系统总的数据流程或高层数据流程。
数据库设计：明确数据库设计的基本原则，进行数据库的概念设计，明确数据库的结构和表的设计，如ER图等。如果使用数据库分析和设计工具，可以用数据文件单独表示。
安全性设计：明确系统针对安全性的设计。
接口设计：明确系统的外部接口、主要模块之间的接口。
数据结构与算法设计：针对数据结构（如队列、堆栈等）和主要的算法进行设计。
界面设计原则：明确界面设计的基本原则，包括界面的基本样式、风格、颜色、字体、操作方便性、报错机制等。
程序设计的基本原则：需要考虑程序的基本组织结构、程序的基本风格等。（在《程序开发规范》中另行明确）。
概要设计说明书编写
设计人员根据总体设计，编制《概要设计说明书》。 该说明书可以是一个整体，也可以按照子系统分别编制。 概要设计评审
项目经理组织评审《概要设计说明书》，并填写《评审表》。《概要设计说明书》需要经过部门经理或和客户批准。
也可由实施部门经理或项目管理部评审《概要设计说明书》。 具体项目的概要设计评审，需要在《项目计划书》中约定。 评审通过后，提交《概要设计说明书》给技术管理部，并入库。 11.2.2.3. 详细设计规范
详细设计内容
概要设计完成后，开始进行系统的详细设计。
IBM银行信用卡系统建设项目
- 62 -
武汉佰钧成技术有限责任公司
详细设计可以按照子系统或某块进行设计，并明确接口实现、数据库设计、数据设计、过程设计、代码组织、程序设计等。
接口设计：详细落实人机界面、内部接口、外部接口（软、硬件）等。 数据库设计：主要是物理模型设计。明确数据库表的结构和字段定义、视图、主要存储过程等。如果使用数据库分析和设计工具，可以用数据文件单独表示。
数据设计：包括全局变量（动态、静态）、临时存储结构、永久存储结构等的详细设计。
处理过程设计：描述具体的功能的实现过程，包括主要的算法、处理流程、具体实现过程（函数和过程等）。
程序设计：根据需要，可以进行程序的设计，明确主要的程序的内部结构。 详细设计文档及评审
设计人员根据详细设计工作的内容，编制《详细设计说明书》。 该说明书可以是一个整体，也可以按照子系统分别编制。
项目经理组织评审《详细设计说明书》。设计需要部门经理或者客户批准。 评审通过后，提交《详细设计说明书》给技术管理部，并入库。 11.2.3. 系统测试规范
计划和案例的制定
在正式测试前，需要制定《测试计划》和《测试用例》。
1、项目经理或测试负责人进行测试安排，明确测试目的、测试范围、测试内容、测试方法、测试环境和测试辅助工具、测试时间进度、测试参与人员和人员分工、测试通过标准等。
2、项目经理或测试负责人根据测试安排的情况，编制《测试计划》，《测试计划》经项目经理组织评审，并由部门经理或技术管理部批准。
3、项目经理或测试负责人组织测试人员编写《测试用例》。对于系统测试，《测试计划》和《测试用例》应在需求阶段编制。对于集成测试，《测试用例》应在设计阶段编制。
4、《测试用例》的编写，需要依据《需求分析说明书》、设计文档、合同等文档。必要时，还要参照上一阶段测试文档或以前的文档。
5、《测试用例》需要经项目经理组织评审，部门经理批准。
IBM银行信用卡系统建设项目
- 63 -
武汉佰钧成技术有限责任公司
6、对于某些部门的成熟产品，可以编制一套成熟的《测试用例》，经部门经理批准后发布。每半年部门经理对其复审，判断是否需要修订；对于项目，则可以直接调用，使用前不必评审。
测试准备
在测试开展前，需要做好充分的准备，包括： 1、配备测试用硬件环境。
2、建立相应的运行环境和网络环境。 3、准备测试数据。 4、准备测试工具。
5、确认测试环境和测试工具。 6、组织和培训测试人员。 单元测试
在编码阶段，要进行单元测试，以保证单元模块的质量。
1、单元测试与开发同步进行，完成某个单元模块后，即可进行单元测试。 2、在测试过程中，要求使用专门的测试问题跟踪工具。 3、单元测试中发现的问题需要进行跟踪解决。
4、单元测试结束后，测试负责人需要提交《单元测试报告》给项目经理。 5、如单元测试不通过而需要紧急放行，应由项目经理签字批准。放行时，编码人员和测试人员应做好记录，并采取措施进行跟踪，待以后解决。
集成测试和系统测试
单元测试通过后，需要进行集成测试和系统测试。 1、先进行集成测试，再进行系统测试。
2、如果在《测试计划》中注明，可以把集成测试和系统测试合并进行。 3、在测试过程中，测试人员应作好测试记录，在《系统问题记录表》中记录测试中发现的问题。也可以直接在《测试案例》中记录。
4、要求使用专门的测试问题跟踪工具。测试中发现的问题需要进行跟踪解决。
5、测试结束后，测试负责人需要提交《测试报告》给项目经理。 6、如测试不通过而需要紧急放行，应由技术部门经理签字批准。放行时，
IBM银行信用卡系统建设项目
- 64 -
武汉佰钧成技术有限责任公司
编码人员和测试人员应做好记录，并采取措施进行跟踪，待以后解决。 11.2.4. 系统开发规范
（一）、编码准备
项目经理应在正式编码之前，组织制定编码规范，并安排编码工作。必要时制定编码计划。
1、编码规范
（1）项目组进行正式编码之前，需要制定或明确编码规范。 （2）编码规范可以是现有的、可以直接引用，也可以是新编制的。 （3）编码规范要根据项目的难度、所用语言等特点而编制。 2、编码计划
项目经理需要明确编码任务，合理进行人员安排、任务分配和进度控制，在需要时可以制定编码计划。编码计划可以单独制定（模板自定），也可以对《项目计划》进行细化。
编码计划主要包括以下几方面内容： （1）细分编码阶段
如果编码阶段较长，则可以进行细分。编码阶段的细分主要根据时间和任务进行，也可根据实际情况制定，但主要编码的每个阶段至少应包括编码、测试和文档记录三项任务。
（2）编码任务
为了便于控制，需要划分编码任务。主要的编码任务包括：编码实现、代码验证、编码修改、文档记录，有时会加入编码走查、单元测试、阶段完成情况总结等任务。明确编码任务和进度要求，评估出编码重心和重点，对于不同的阶段和不同的任务强度进行合理的分配和要求，并明确每个阶段的周期和每个编码人员的进度要求。
（3）人员安排
安排每个编码人员的职责、任务及周期。对于不同阶段和任务，人员参与顺序和变动情况进行计划。如果编码任务强度大，文档编写和测试工作的人员要提前安排。
（4）编码进度
IBM银行信用卡系统建设项目
- 65 -
武汉佰钧成技术有限责任公司
明确每个编码阶段和编码任务的时间进度，并能够对特殊情况造成二次开发的时间进行预计。
（5）资源需求
明确需要和可利用的开发工具、设备、成本及其他人力资源等环境资源，在不同阶段有效进行分配。
编码
1、项目组编码人员按照编码的计划安排进行编码工作。 2、编码时，需要按照编码规范的要求编写代码。
3、编码人员在进行编码时，需要进行编码验证，保证编码质量。 4、在进行编码时，项目经理根据需要组织代码走查。 5、编码完成后，需要进行单元测试。
6、在编码阶段，还可能需要编制操作手册等文档。 7、编码阶段发现的问题需要及时改正。 代码走查
项目经理可以在适当时机安排代码走查，对编码工作进行检查，代码走查主要依据《编码规范》的要求，对于代码走查中的问题需要及时发现、及时提出意见、及时记录、及时改进。
代码走查的主要工作内容： 1、确定代码走查的范围和内容 2、明确代码走查时间、人员
3、核心算法、复杂模块和新手编写的程序是代码走查的重点 4、记录代码走查的结果（包括问题）
5、讨论代码走查中发现的问题，提出意见和要求 6、编码人员要根据代码走查情况修改代码、改进编码工作 代码验证和单元测试 1、代码验证
编码完成后，开发人员需要自行验证代码的正确性，保证代码能够运行、实现基本的功能。
2、单元测试
在各个模块单元编码完成后，测试人员或编码人员需要进行单元测试，包括
IBM银行信用卡系统建设项目
- 66 -
武汉佰钧成技术有限责任公司
对完成的运行程序、功能模块或系统进行测试，以确保单元模块的准确可靠、发现并解决单元模块中的问题，并以此为依据对下一阶段任务进行调整。
错误排查
在编码后期，还需要对代码进行检查，以便排除编码中存在的问题和错误。包括代码走查、编码验证和单元测试中发现的问题，需要进行重新测试或排查。
文档编写和代码提交
如果需要编写操作手册等文档，项目经理还需要在本阶段安排人员进行文档编写工作。手册需经过项目经理审核。项目经理提交代码给测试人员，以便进行测试。
12. 项目质量保证体系
佰钧成历来重视工程实施中的项目管理，并以ISO9001质量体系作为我们提供优质服务的标准。并且在2007年公司的湖南农信大额支付系统通过了SEI专家的CMMI3评估一。一个工程从立项到实施，到最终提交给用户及提交后系统的维护和产品维修，都有非常严格的制度和流程。这样做，不但能确保我们的工作可以按步骤有计划地进行，最重要的是确实保证了用户的利益，保证了我们提供的产品及服务满足用户的需要，并提高了我们自身的服务能力。
佰钧成ISO9001程序文件中规定了应用软件开发、安装、调试、培训、维护、维修的质量控制方法和要求，同时也规范了每个有关工作人员的工作顺序，规定了相关人员的工作要求从而保证了产品和服务的质量。
1998年，佰钧成通过ISO9001质量管理体系认证。通过ISO9001质量管理体系，佰钧成在项目开发管理方面取得了良好的效果。
✓ 通过推行ISO9001，可以全面提升佰钧成的管理水准并与国际接轨。 ✓ 全方位提升佰钧成的产品质量，并减少各种浪费降低公司的生产成本，
增强公司产品的市场竞争力。
✓ 可以全方位提升佰钧成内管理者及员工的质量意识与管理能力，进而提
升工作效率及团队凝聚力。
✓ 通过ISO9001的认证成功，向客户展示所获得的国际公认的权威认证证
书，以全面提升组织在国际及国内行业中的形象及影响，为佰钧成创造出更多的商机与发展机会。
IBM银行信用卡系统建设项目
- 67 -
武汉佰钧成技术有限责任公司
✓ 全面增加顾客对组织的信任度及满意度。
针对本项目，我公司会派遣资深的质量经理和公司QA参与项目。他们负责确保项目遵守质量保证体系的标准要求，确保遵循项目计划书中描述的要求，确保交付的软件及其文档以及非交付的软件在需求、设计及管理等诸多方面的质量。
质量经理监控项目成员的软件活动，并对软件产品与可适用的标准、过程和软件开发计划的符合性进行评价，为双方项目领导小组监控项目的软件生产提供适当的可视性。
质量经理负责对项目进行监控与分析，将结果报告给由双方高层人员组成的项目领导小组。项目经理批准发布给用户的所有文档和软件，必须得到质量经理的复核和批准。
质量经理的工作依据为行业标准和公司的管理规范，工作方式为评审和审计。
12.1. 质量保证目标
（1）遵循成熟的管理过程执行本项目；
（2）确保交付的软件及其文档质量达到行业标准；
（3）确保交付的软件及其文档经过内部审查和评审，软件系统开发文档和软件系统使用帮助文档要求具有完整性、一致性和方便性；
（4）确保各实施过程经用户参与和检验； （5）最终实现客户满意。
12.2. 质量保证角色与职责
角 色 项目经理 职责 （1）负责项目产生的软件和相关文档的质量 （2）带动项目成员配合和支持质量保证活动 （3）协商确定将要执行的质量保证活动，协助质量保证人员编写质量保证计划 （4）评审和批准项目的质量保证计划 （5）执行质量保证计划，遵守组织标准 （6）跟踪和解决SQA提出的质量问题 （7）收集和提供度量数据，以及质量保证检查所需的项目信息 IBM银行信用卡系统建设项目
- 68 -
具体对应人员 杜轶 武汉佰钧成技术有限责任公司
角 色 质量保证组人员 职责 （1）协助项目组进行过程裁剪，参与软件项目计划的制订。 （2）促进和推动软件项目各阶段的质量检查。 （3）通过《项目周报》和《项目月报》、《里程碑报告》等收集项目信息，并进行总结和分析。 具体对应人员 （4）评审项目执行过程、审核工作产品，将审查结果记录在《过程检查表》和《产品检查表》中，较大偏差记入《问题跟踪表》，跟踪问题直至解决。 朱艺 （5）将在项目级不能解决的不符合问题汇报给项目经理，跟踪问题直至解决。 （6）利用《QA工作周报》或《个人工作周总结》汇报QA活动的实际进展 （7）参加项目例会。，介绍QA活动的状况，同时沟通问题、风险和变化 （8）分析和指导使用度量数据 项目组成员 （1）评审质量保证计划 （2）遵循项目标准过程，按照要求产生项目成果。 （3）配合质量保证员的检查
IBM银行信用卡系统建设项目
- 69 -
武汉佰钧成技术有限责任公司
12.3. 质量保证流程
质量保证流程输入项目总监质量保证员开始项目经理项目组成员输出协助项目过程定义项目过程定义协助项目计划的编写项目总体计划项目总体计划质量保证指导书编写质量保证计划质量保证计划的确认质量保证计划进行项目过程和产品检查过程和产品检查表问题上报问题上报单项目周报里程碑报告问题处理问题跟踪问题跟踪表质量保证工作报告结束质量保证总结报告 12.4. 质量保证活动
12.4.1. 协助项目过程定义
（1）提供公司级的过程裁减指导书
（2）质量保证员配合项目经理根据已定义的项目生命周期阶段，帮助裁减项目过程定义，选择和确认该项目所需要的活动，每个活动的产出物。
（3）经过双方领导审批通过。 12.4.2. 协助项目计划的编写
（1）提供总体项目计划标准模板，并提供指导和解释
IBM银行信用卡系统建设项目
- 70 -
武汉佰钧成技术有限责任公司
（2）帮助设立项目所能达到的目标
（3）根据裁减说明进行裁减确定项目计划所包含的内容
（4）共同协商项目所需的不同类型的项目计划（比如阶段计划、专题计划、项目工作规范）
12.4.3. 质量保证计划编写与确认
（1）质量保证员根据项目总体计划和质量保证指导书编制质量保证计划，质量保证计划按照标准模板编写，主要包括：质量保证活动安排（项目过程检查、项目工作产品检查内容）、进度计划。
（2）由项目经理、项目组成员对质量保证计划进行评审。
（3）项目经理对质量保证计划进行确认，并且纳入项目的配置管理。 12.4.4. 项目过程和产品检查
项目过程与产品检查内容
项目过程和产品检查活动，显示如下表“项目过程和产品检查活动”所示：
IBM银行信用卡系统建设项目
- 71 -
武汉佰钧成技术有限责任公司
检查类别 产品检查检查活动 测试环境检查 代码检查 上线环境检查 测试用例检查 项目总体计划 项目过程裁剪表检查 需求规格说明书检查 产品发布检查 产出物 测试环境检查表 代码检查表 上线环境检查表 测试用例检查表 项目总体计划检查表 项目过程裁剪表检查表 需求规格说明书检查表 产品发布检查表 系统上线检查表 决策分析检查表 配置管理检查表 评审检查表 项目过程裁剪检查表 项目计划检查表 度量分析检查表 风险管理检查表 里程碑检查表 项目监控检查表 需求开发检查表 需求管理检查表 参考频率 分几次测试查几次 不少于两次 分几次上线查几次 单元测试用例一次+集成测试用例次+系统测试用例一次 计划时一次+计划变更次数 过程裁剪时一次+过程裁剪变更次数 编写完成时一次+变更次数 分几次上线查几次 分几次上线查几次 决策几次查几次 计划时一次+配置审计次数 评审几次查几次 过程裁剪时一次+过程裁剪变更次数 计划时一次+计划变更次数 每个里程碑 每个里程碑 每个里程碑 每个里程碑 一次，当项目有迭代的阶段时，按迭代次数 每个里程碑 检查人 技术负责人 技术负责人 技术负责人 质量保证员 质量保证员 质量保证员 质量保证员 质量保证员 质量保证员 质量保证员 质量保证员 质量保证员 质量保证员 质量保证员 质量保证员 质量保证员 质量保证员 质量保证员 质量保证员 质量保证员 过程检查系统上线检查 决策分析检查 配置管理检查 评审检查 项目过程裁剪检查 项目计划检查 度量分析检查 风险管理检查 里程碑检查 项目监控检查 需求开发检查 需求管理检查 IBM银行信用卡系统建设项目
- 72 -
系统设计检查 系统测试检查 项目结项检查 项目验收检查 武汉佰钧成技术有限责任公司
系统设计检查表 系统测试检查表 项目结项检查表 项目验收检查表 编写完成时一次+变更次数 一次，当项目有迭代的阶段时，按迭代次数 一次，当项目有迭代的阶段时，按迭代次数 一次，当项目有迭代的阶段时，按迭代次数 质量保证员 质量保证员 质量保证员 质量保证员 IBM银行信用卡系统建设项目
- 73 -
武汉佰钧成技术有限责任公司
项目过程与产品检查形式
质量管理员通过参与项目的各种重要会议，参与一些重要的管理活动，包括与项目经理和项目组成员进行沟通，以达到对项目过程的检查目的；通过对项目文档的检查和审核，以及与相关人员的沟通达到对项目产品检查的目的。
质量管理员参与的项目组的管理活动： （1）项目质量管理例会
项目质量执行例会，是项目质量管理的最重要的活动。 参加人员：质量经理、项目经理、项目核心组成员。 主持人：质量经理
会议内容：总结各小组在各阶段的工作是否达到或满足质保计划的要求，以及改进措施
递交件：《项目质量管理例会会议纪要》 执行频度：在项目每个阶段的开始。 （2）项目每周例会
项目每周例会，是项目组一般情况下的主要管理活动。 参加人员：项目经理、成员。 主持人：项目经理
会议内容：总结上周计划执行情况，审查下周工作计划。解决项目中的问题。 递交件：《项目周报》 执行频度：每周一次。 （3）项目技术和管理检查会
项目技术和管理检查会，是项目组不定期的对于技术或管理的自我检查活动。
参加人员：项目经理、成员。
主持人：项目经理或项目核心组成员。 会议主持人：项目经理或项目核心组成员。 递交件：《会议纪要》 执行频度：视需要而定。 （4）里程碑审查会
IBM银行信用卡系统建设项目
- 74 -
武汉佰钧成技术有限责任公司
里程碑审查会：在项目进程中的关键点（如需求确定、设计完成），组织较大规模的审查活动，以帮助项目组防范风险。
参加人员：项目组主要人员，客户方的后援机构，公司的后援机构。 递交件：《会议纪要》和《里程碑检查表》 执行频度：根据需要而定。 （5）评审会
评审会：在项目总体计划、需求规格说明书、系统设计说明书、系统测试方案等需要客户方参与评审的重要会议，质量保证员需要参加，一些内部的评审会议和重要的讨论会议也最好能够参加。
主持人：客户方领导，或我方项目经理
参加人员：项目组主要人员，客户方的后援机构，公司的后援机构 递交件：《评审报告》
执行频度：文档确定需要评审，同时变更也需要评审。 （6）务虚会
务虚会：比较自由的一种会议，一般用来发现项目管理中的漏洞和风险。 参加人员：不限。 递交件：《会议纪要》 执行频度：根据需要而定。 12.4.5. 问题上报
质量保证活动发现的问题，首先考虑项目组内部进行解决。对于项目组内部无法解决的问题，采取上报的方式。
上报的原则：
项目组内部没有达成解决办法； 解决问题的时间不合适，无法保障； 解决方法有悖于公司总体方针。
质量保证活动过程中发现的问题，记录在《问题跟踪表》中，项目经理负责对问题进行跟踪直至关闭。质量保证员采取抽查的方式对问题跟踪表内的问题进行状态跟踪。
对于项目组内部无法解决的问题，通过《问题上报单》上报项目主管同时抄
IBM银行信用卡系统建设项目
- 75 -
武汉佰钧成技术有限责任公司
送质量保证经理，由质量保证员负责进行跟踪直至关闭。 12.4.6. 质量保证工作总结
每周，质量保证员将质量保证活动情况汇报给质量保证经理，提供项目周报中质量保证部分内容；
每个里程碑，质量保证员将质量保证活动情况汇报给质量保证经理，提供里程碑报告中质量保证部分；
项目结项时，质量保证员进行质量保证活动总结，向质量保证经理汇报。
IBM银行信用卡系统建设项目
- 76 -
武汉佰钧成技术有限责任公司
13. 项目进度控制方案
13.1. 项目进度跟踪
在项目的实施过程中，对项目的实施情况进行跟踪，确保项目的实施符合计划的要求。跟踪的方法分为正规跟踪和非正规跟踪，正规跟踪就是定期召开项目进展情况汇报会、提交项目进展报告等，从而使项目利益相关者了解项目的执行情况。根据进展报告，与会者讨论项目遇到的问题，分析并找出问题的原因，研究、确定应对方案和预防措施，为控制项目提供依据。
非正规跟踪则是项目经理频繁地到项目现场，通过观察、与现场人员交谈、收集数据等方式了解情况，发现问题，以此方式进行跟踪，对项目的进度控制有 较大的作用，经我们以往的项目管理证明，此方式有以下特点：
了解的情况真实、及时；
缩小了项目经理与现场成员之间的距离，使之关系更融洽，问题更易解
决；
现场的执行人员更容易沟通；
项目经理更能亲身体会现场的工作气氛，掌握团队的士气； 更容易获取解决问题的答案；
在对项目任务进度的度量上，我们把每项工作分解到工期在一周以内，每周末进行进度评估，通过每位项目组成员按周提交工时来进行控制，即每周均需提交工作任务的完成工时。
在项目进度信息采集方面，我们通过项目周报、项目例会、阶段性评审来进行控制：
项目周报：就是项目实施小组每周向项目经理提交每周的工作汇报，包
括存在问题。
项目例会：就是项目组定期举行工作会议，分析项目状态，落实下一步
工作，其中包括对现有的问题进行讨论并解决。
阶段性评审：就是在项目的阶段最后，召开项目小组成员、项目指导委
员会、外部项目质量保证等人员对项目的阶段工作进行评审，包括进度、交付物的质量、阶段里程碑、项目中的重大问题、项目风险、分析项目
IBM银行信用卡系统建设项目
- 77 -
武汉佰钧成技术有限责任公司
中的好的方法等。
13.2. 项目进度分析
我们通过挣值法进行项目进度分析，通过提供三个数据来跟踪项目的执行情况，即：计划做什么、实际做什么、以及做完的工作花了多少费用？这种方法交计划需完成的工作同实际已完成的工作进行比较，确定项目在费用支出与时间进度方面是否符合原计划的要求，从而跟踪项目执行的好坏。
13.3. 项目进度控制
项目计划只是根据预测而对未来做出的安排，由于在编制计划时事先难以预见的问题很多，在计划执行过程中往往会发生或大或小的偏差，这就要求项目经理及其他管理人员对计划做出调整，消除与计划不符的偏差，以使预定目标按时和在预算范围内得以实现。
项目计划的控制就是要经常对每项工作进度进行监督，然后，对那些出现\"偏差\"的工作采取必要措施，以保证项目按照原定计划进度执行，使预定目标按时和在预算范围内实现。
在项目实施中，我们根据不同管理层次对进度控制的要求分为以下三类： 项目总进度控制：项目领导小组对项目中各里程碑事件的进度控制。 项目主进度控制：项目经理针对项目进度计划中的关键路径进行控制，
保证总进度的如期完成。
项目详细进度控制：主要是各小组负责人对各具体作业进度计划的控
制。这是进度控制的基础，只有详细进度得到较强的控制才能保证主进度的按计划进行，最终保证项目总进度，使项目目标得以顺利实现。 我们进行进度控制的依据主要有：项目进度表、项目进展报告、变更请求等。在本项目中，我们主要的项目进度的控制方法有如下一些：
➢ 项目采用封闭开发，开发地点由需方选定，试运行期间供方的开发组到
需方指定的地点对系统功能修改和完善；
➢ 把能力强的成员放在关键路径的工作上，把新手放在时差大，不重要的
工作上；
➢ 赶工期，包括通过加班加点来缩短关键路径上单项任务的持续时间；调
IBM银行信用卡系统建设项目
- 78 -
武汉佰钧成技术有限责任公司
整关键路径上活动之间的逻辑关系，变FS为SS； ➢ 对于一些有成熟工具的开发内容，我们通过采购解决等；
➢ 投入更多的资源，看看可否通过增加人力、设备到工作中来控制进度； ➢ 确定功能的优先级，对优先级别高的先确保交付，优先级较低的功能放
在项目后期开发，保证项目进度满足业务需求；
➢ 提供奖金，看看能否提供奖金或其他激励措施，促使按时完成任务；
14. 售后服务承诺
武汉佰钧成技术有限责任公司系统有限公司坚持以用户为中心，以本地化服务为宗旨，依托武汉佰钧成技术有限责任公司系统有限公司服务为您提供完备的技术支持与售后服务。想您之所想、急您之所急，我们一直在努力。
武汉佰钧成技术有限责任公司系统有限公司承诺技术后援支持，为系统提供三年免费的应用软件维护本地化服务，每季度一次系统巡检，检测、维护服务。
14.1. 服务承诺
我公司特别承诺：提供IBM银行信用卡系统评论网站项目的售后全程服务，向用户提供操作性强的《技术维护手册》和《故障应急处理手册》，在1年的免费服务期内，我们在客户有相关需求的情况下，安排有经验的专职技术人员，对影响生产的软件故障提供7*24服务，半小时内响应，1小时内提供补救方案，8小时内修正；对不影响生产的软件故障，提供7*24服务，半小时内响应，2日内修正，同时提供其他的售后服务和培训服务等。 14.1.1. 质量保证承诺
我们承诺为系统提供“全天候7x24小时”的技术支持与运行维护服务，确保平台系统安全、稳定、高效的运行：
✓ 提供一年免费的应用软件维护本地化服务，承诺服务不转包。 ✓ 提供完善的故障解决方案，并定时（至少每季度一次）主动到用户方进
行系统巡检。
IBM银行信用卡系统建设项目
- 79 -
武汉佰钧成技术有限责任公司
14.1.2. 免费技术咨询
✓ 我们承诺对本项目提供终身免费技术咨询服务；
✓ 对与本项目招标内容紧密相关的技术问题，我们承诺给出清楚明了的技
术答复，答复方式主要为专业人员的电话答复和电子邮件；
✓ 对与本项目相关但本次招标内容不包括的技术问题，我们承诺尽可能给
出用户满意的技术答复，答复方式主要为专业人员的电话答复和电子邮件；
✓ 公司承诺电话答复2个小时之内完成，电子邮件答复在1个工作日内完
成。
14.2. 服务响应承诺
14.2.1.1. 故障等级划分
公司将故障划分如下五个等级。 第一级：重大系统故障
在运转期间，任何系统服务中断导致严重影响系统功能和用户不能使用系统的这类故障。
第二级：严重系统故障
在运转期间，导致主要系统质量下降、影响用户及维护人员操作的可以短暂容忍的故障。
第三级：一般系统问题
在运转期间，没有严重影响的非系统服务及质量下降，不会对用户及维护人员有重大影响的问题。
第四级：某些功能不会使用或操作问题
在运转期间，有某些功能不会使用或者由于操作上的问题造成轻微故障，不影响客户的正常使用。
第五级：增加新功能
客户提出增加软件功能要求。依据客户提出的具体要求，协商解决期限。
IBM银行信用卡系统建设项目
- 80 -
武汉佰钧成技术有限责任公司
14.2.1.2. 服务响应承诺
售后技术支持服务 解决时限 第一级：重大系统故障 1-2小时内。 第二级：严重系统故障 48小时之内。 第三级：一般系统问题 立即反应，在不影响客户使用的情况下，逐步解决。 第四级：某些功能不会使用或操作问题 立即反应，在不影响客户使用的情况下，逐步解决。 第五级：增加新功能 与客户协商解决 14.3. 服务目标
我们服务的基本目标是用户满意，我们向用户承诺提供高效、便捷、专业、个性化的售后服务，随时听取客户的意见。公司一直以来把用户的利益放在最高标准上，深信用户利益的保障也就是公司无形资产的增长，而用户利益的保障很大程度上取决于售后服务的支持。为此，公司制定了实施及服务方式，具体讲即；从项目开始设计、实施、交付运行整个过程中，与用户反复探讨，深入了解要求，尽最大可能在项目完成的同时，为用户在技术上培养起一支过硬队伍，可以由用户自身现场解决实际问题，达到科技的普及化，以适应市场的迅速变化。
三大技术支持与服务目标是：
✓ 提供无忧环境。计算机和网络系统是信息系统的关键，我公司将集中公
司的技术资源，采取一套完整的系统和网络管理工具，全力解决用户遇到的技术问题和故障。同时以预防为主，负责制定相应的预防保养计划和措施，积极协助用户解决信息系统运行中的隐患，提升系统性能，减少系统停机时间，保障系统正常运行，提高投资回报率。
✓ 确保计算机应用开拓和发展。我公司负责向用户传递相关领域的计算机
发展方向和产品信息，同时提供系统设计、安装、性能分析、应用软件
IBM银行信用卡系统建设项目
- 81 -
武汉佰钧成技术有限责任公司
开发咨询、增值服务等，确保系统处于同行业领先地位。
✓ 技术转移。通过对用户系统管理人员和操作人员多层次、多方位的技术
培训/咨询和日常操作指导，提高该部分人员的技术水平及工作效率，帮助用户建立一支专业技术队伍。
14.4. 服务策略
✓ 服务标准化。基于符合国际标准的质量控制体系，形成标准化的作业流
程，标准化的文挡、标准化的服务用语等。
✓ 服务电子化。针对具备上网条件的用户，提供远程登录、WEB互动、在
线支持等电子化服务内容，逐步建立完善的电子化服务渠道。 ✓ 服务周到化。倡导基于用户满意度为100%的个性化关怀；满足用户标准
化服务以外的特殊使用需要。
✓ 服务主动化。定期回访制度，针对客户问题比对历史案例，提出预先解
决方案，并保证服务在短时间内到位。
14.5. 服务方式
客户服务中心采用多种方式提供技术服务：
✓ 热线电话(传真)即时指导服务：当我公司开发的软件系统发生问题时，
首先由用户方的技术人员对故障现象、故障信息进行详细的观察记录，然后通过热线电话通报我公司，由我方技术人员进行故障会诊，确认合适的解决方案，然后指导用户方人员进行现场操作，排除故障(永久有效)。
✓ 现场服务：当用户系统发生故障时，用户方面及时通知我公司，电话解
决无效时，公司将派出工程师在第一时间到达用户现场进行维修。 ✓ 预防性服务：公司将定期对用户系统进行巡回检修，到用户现场进行系
统检查、专业咨询等服务（质保期内或购买了售后支持服务且在服务期内）。
✓ 定期专访：公司将定期（至少一季度一次）派人对用户系统的工作环境、
运行状态、性能、安全性等方面进行检查。如有问题则进行维修（质保期内或购买了售后支持服务且在服务期内）。
IBM银行信用卡系统建设项目
- 82 -
武汉佰钧成技术有限责任公司
✓ 问题与解答技术支持库：公司集多年在应用软件系统领域的开发、设计、
实施经验，在公司的服务器上专门建立了一个问题与解答库，为用户提供在线的免费技术支持，解答系统使用中的常见问题。
✓ 系统调整服务：在用户系统运行一段时间后，我方技术人员和高级技术
顾问将到用户现场对整个系统性能进行优化服务，以确保整个系统的安全、高效运行（质保期内或购买了售后支持服务且在服务期内）。 ✓ 系统升级和更新换代：公司将根据用户系统的发展需求，帮助用户对系
统进行升级和更新换代。
IBM银行信用卡系统建设项目
- 83 -
武汉佰钧成技术有限责任公司
15. 培训保障方案
培训是应用系统开发和系统集成工作的重要组成部分，通过优质的培训可以为本系统的顺利实施及可靠运行打下良好的基础。培训的一般目的在于：培训相关技能和知识，使之能有效地、高效地履行职责，满足岗位需要。
具体的，对于公司来说，培训是为了满足员工职业发展和企业发展战略的需要，实现员工能力和企业核心能力提高的“双赢”；
特别的，对于用户而言，培训是为了实现承建商和用户之间的知识转移，从个人确保客户需求、客户业务战略的实现。培训是项目实施成功的关键；项目实施过程中，我们尤其注重对各个层次人员的培训工作。
为了充分发挥系统的效益，平滑的向用户实现项目技术转移，一般的，可根据项目产品、知识系列的划分，安排相应的现场培训、专业技能培训，用户之间、用户与我们之间的岗位轮换，通过这些培训，最终实现：
·用户技术人员能够熟练掌握应用系统的运行维护方法，能够独立安装和调试目标系统。
·用户技术人员能够熟练掌握应用系统的使用和管理。
佰钧成公司具有多年的软件开发及系统集成经验，拥有一支强有力的培训师资队伍。在本项目中，佰钧成公司将精心地规划、组织管理类、技术类和业务类的培训，主要包括使用培训、系统培训和业务管理培训等，涉及人员有业务人员、系统维护人员、项目管理人员等。
在本次招标文件中，对培训服务工作提出了具体、严格的要求，佰钧成公司以此为基础，并结合以往的经验，对本项目的内容进行了认真的设计和细致的规划。同时，在培训工作中我们将做到精心准备、细致安排、积极实施、及时总结。
本部分内容将对培训方案进行详细说明。
15.1. 培训承诺
（1）我公司承诺，提供相应的管理培训、技术培训和业务操作培训；有关技术和操作培训课程在系统正式运行前完成。
（2）我公司承诺，对于本项目的培训，所有培训讲师都具有相应专业资格和实际工作、教育经验。
IBM银行信用卡系统建设项目
- 84 -
武汉佰钧成技术有限责任公司
（3）我公司承诺，对于人行各部门工作人员的应用系统培训，不限制客户方参加此类培训的人数，培训名额由客户方确定。除培训计划外，在系统运行期间若客户方有培训要求，我公司将根据实际情况而协助客户方完成相关培训。
（4）我公司承诺，我公司会按合同规定安排培训时间。
15.2. 培训目标和内容
15.2.1. 培训需求
根据招标文件的要求，本项目的培训对象为IBM银行信用卡系统各部门业务人员、系统维护人员、项目管理人员等，培训的内容应包括软件、数据库以及其它相关技术培训，主要侧重于对该系统的使用及系统的基本维护、常见问题及解决办法等，并提供实践性的操作，旨在使受训者熟悉系统设计的思路，掌握系统的操作和维护等。
本项目中主要包括的培训有： （1） 开发培训
对武汉营管部参与本系统开发的人员进行相关技术培训，使其能参与本系统的日常开发及后续的内部维护管理工作。
（2） 使用培训
对业务部门工作人员进行培训，使得使用者可以独立地、熟练操作业务系统。 （3）系统培训
对本项目中的系统应用模块的日常维护、监控管理、操作的培训。需要提供详细的日常维护方法和工作流程。
（4）业务管理培训
针对与管理信息平台相关的各种部门的工作流程，制定工作流程制度，并提供相关培训。
培训的地点由我公司解决或由IBM确定。 15.2.2. 培训目标
主要为IBM银行信用卡系统各部门的领导干部、业务人员、项目管理人员、系统维护人员、数据管理人员提供所需要的管理类、业务类、技术类、操作类的培训，一方面，让他们熟悉该系统的业务流程和设计思想，另一方面，让他们熟
IBM银行信用卡系统建设项目
- 85 -
武汉佰钧成技术有限责任公司
悉该系统的操作，同时，系统维护人员能够熟悉系统应用模块的日常维护、监控管理、操作等。培训的主要内容侧重于对该系统的使用及系统的基本维护、常见问题及解决办法等问题，并提供实践性的操作，旨在使受训者熟悉系统设计的思路，掌握系统的操作和维护等。
15.3. 培训类别
为了保证该项目的顺利建设和高效运行，需要对评论网站项目从上而下，针对不同对象、开展不同层次、不同类型的培训：
首先根据培训对象的不同，可以分为以下几类： （1）领导干部
为了使系统顺利建设、高效运行，需要一只高素质的管理队伍，所以需要对领导开展一系列信息化和项目管理知识培训。
（2）项目管理人员
为了保证该项目的正常运行，客户方需要派出一定的管理人员配合我方参与项目的一些管理工作，我方需要对我们的系统总体架构、系统的设计、项目管理规范和一些流程规范进行一些培训，提高客户方项目管理人员对该项目的总体认识，并在管理规范方面与我方达成一致意见，便于沟通和交流，更好的参与到项目的项目管理和监控。
（3）系统维护人员
客户方的系统维护人员需要对该系统的硬件系统、网络系统、软件系统、系统各应用模块提供日常维护、监控管理和系统操作，所以需要对系统维护人员从业务、系统的架构、系统的设计思想、系统的技术实现、系统的配置与搭建、系统的日常维护方法以及维护工作流程等各个方面进行培训，提高系统维护人员对系统的技术理解能力和对系统的维护能力。
（4）业务人员
业务人员参与系统的一些建设工作，同时也是该系统的使用者，需要提供系统的操作和管理信息平台的工作流程的培训，以便分清大家的职责。
其次，根据培训课程的内容，可以区分为以下几类： （1）管理类培训
包括对领导干部、项目管理人员提供一些管理方面的培训。
IBM银行信用卡系统建设项目
- 86 -
武汉佰钧成技术有限责任公司
（2）技术类培训
包括对系统维护人员、领导干部、项目管理人员的一些技术架构、设计理论、技术方面、工具等的培训。
（3）业务类培训（业务管理培训）
针对与内审综合控制系统相关的工作流程，制定工作流程制度，撰写培训教材，并提供相关培训。同时对该系统的一些关键业务进行培训和指导。
（4）操作类培训（使用培训和系统培训）
对业务部门工作人员进行系统操作培训，使得使用者可以独立地、熟练操作业务系统。对系统维护人员进行硬件系统、网络系统、系统软件、系统应用模块的日常维护、监控管理、操作的培训，提供详细的日常维护方法和工作流程。主要针对该系统的一些操作方面的相关知识进行培训。
15.4. 培训课程
佰钧成培训中心拥有一支专门负责课程开发的专家队伍，本着为客户“培训运营技能，提高投资回报”的宗旨，将产品开发理念贯穿到课程开发中，历经市场调研、设计、开发以及教学效果评估等四个阶段，充分保证培训质量，满足客户培训需求。
根据客户需要和产品特点，长软培训采用模块化的课程设计思想，各标准模块间灵活组合，可以满足客户的特定需求，以保证最佳的培训效果与效率。
培训内容： 应用软件培训：
对IBM银行信用卡系统相关人员进行10天的应用操作培训。 培训地点： 另议 培训时间： 另议
15.5. 培训方式
培训方式根据项目特点确定。 传统的培训方式有：
IBM银行信用卡系统建设项目
- 87 -
武汉佰钧成技术有限责任公司
·项目研讨会 ·课堂教学 ·上机实际操作 ·用户现场指导等
传统培训方式之外，我们还可提供：电子书籍、电子演示培训系统等多种新型培训方式；
在用户培训课程结束后，用户可在任何时间通过电话、传真等方式向我方进行技术咨询，我方将有专人负责解答。
IBM银行信用卡系统建设项目
- 88 -
因篇幅问题不能全部显示，请点此查看更多更全内容