银行信用卡系统技术方案

年4月19日银行信用卡系统技术方案文档仅供参考星展银行信用卡系统技术方案投标人名称:武汉佰钧成技术有限责任公司日期:二○一一年三月一日前言根据项目要求,武汉佰钧成技术有限责任公司需要完成星展银行信用卡系统的开发、测试、试运行、直至最终的交付使用,负责人员的培训和后期的维护等工作,经过我们对招标文件的分析和理解,我们认为要完成这些工作任务,必须对该项目的业务现状及未来发展目标有较为全面的理解,并有能力进一步的深入细化。以此为基础,我们提出本系统承建方案。为了能帮助各位领导快速的了解整个技术方案编写的思路,我们将各个部分和章节进行了概括性的描述,具体如下:第一部分,技术方案。在第一部分中,主要阐述了公司对本项目用户需求的理解、对项目建设目标和原则的理解,提出系统设计的指导思想,以及系统架构的设计方案,功能的设计以及安全设计方案,关键技术点的实现方法等。第二部分,项目实施及服务方案。在第二部分中,主要陈述了公司在本项目建设过程中将严格参照ISO9001质量保证体系规范和CMMI管理体系,体现我们专业实施能力和项目组织、管理能力;同时,还包括对项目组的人员组成结构,以及对项目的总体计划安排,对项目进度、质量的控制,培训及售后服务的承诺等。作为湖北省IT服务的主流企业,武汉佰钧成技术有限责任公司有能力、有实力承建该项目,为星展银行信用卡系统的建设贡献我们的绵薄之力。最后,预祝本次项目工作取得圆满成功!武汉佰钧成技术有限责任公司3月

目录TOC\o"1-5"\h\z\u第一部分技术方案 81.总体设计 91.1.总体设计原则 91.2.总体设计思路 91.2.1.采用统一顶层设计方法 91.2.2.顶层设计方法的含义 91.2.3.顶层设计对象 101.2.4.采用成熟快速开发平台 111.3.界面设计原则 111.4.技术架构 122.OS／390系统 122.1.OS／390技术特点 122.2.信用卡系统结构 133.需求分析 163.1.总体目标 163.2.信用卡系统业务需求分析 173.3.系统安全需求 184.相关技术 194.1.IBM公司的SNA网络技术 194.2.IBMWebSphereMQSeries中间件 194.3.CICS中间件 215.系统的详细设计与实现 215.1.企业端与银行端的通讯实现 216.运行环境 256.1.软件平台 256.2.开发工具说明 25第二部分项目实施及服务方案 266.项目组织与管理 276.1.项目干系人分析 276.2.项目组织结构 276.3.主要人员投入 286.4.佰钧成的项目服务管理体系结构 296.4.1.公司级管理服务体系 296.4.2.项目级服务管理体系结构 297.项目实施计划 307.1.项目阶段划分 317.2.项目总体计划 317.2.1.准备阶段 327.2.2.需求阶段 327.2.3.设计阶段 337.2.4.开发阶段 337.2.5.集成测试阶段 347.2.6.试运行、上线及终验阶段 347.2.7.运营维护阶段 347.2.8.贯穿各阶段的其它任务 358.项目成果和交付物 359.项目风险计划 369.1.项目风险分析 369.1.1.宏观风险分析 379.1.2.微观风险分析 389.2.主要风险识别及缓解措施 409.3.其它风险控制措施 4310.项目测试与验收方案 4510.1.项目测试方案 4510.1.1.测试概述 4510.1.2.测试目标和原则 4510.1.2.1.测试目标 4510.1.2.2.测试原则 4510.1.3.测试组织 4610.1.4.测试内容 4610.1.5.测试步骤 4910.1.6.测试过程进度及质量控制 5010.2.验收方案 5110.2.1.概述 5110.2.2.验收标准 5110.2.2.1.验收方案的原则 5110.2.2.2.系统验收标准 5210.2.2.3.问题级别定义 5310.2.2.4.测试经过标准定义 5310.2.2.5.测试异常的定义 5410.2.3.验收流程 5410.2.4.验收方式 5510.2.5.验收内容 5510.2.5.1.软件系统 5510.2.5.2.过程文档 5611.项目实施制度和规范 5611.1.实施制度 5611.1.1.决策制度 5611.1.2.沟通汇报制度 5711.1.3.需求管理制度 5711.1.4.变更管理制度 5811.1.5.配置管理制度 5811.1.6.问题管理制度 5811.1.7.文档管理制度 5911.2.实施规范 6011.2.1.质量管理规范 6011.2.2.分析设计规范 6111.2.2.1.系统分析规范 6111.2.2.2.概要设计规范 6211.2.2.3.详细设计规范 6311.2.3.系统测试规范 6411.2.4.系统开发规范 6612.项目质量保证体系 6812.1.质量保证目标 6912.2.质量保证角色与职责 6912.3.质量保证流程 7112.4.质量保证活动 7112.4.1.协助项目过程定义 7112.4.2.协助项目计划的编写 7112.4.3.质量保证计划编写与确认 7212.4.4.项目过程和产品检查 7212.4.5.问题上报 7612.4.6.质量保证工作总结 7713.项目进度控制方案 7813.1.项目进度跟踪 7813.2.项目进度分析 7913.3.项目进度控制 7914.售后服务承诺 8014.1.服务承诺 8014.1.1.质量保证承诺 8014.1.2.免费技术咨询 8014.2.服务响应承诺 8114.2.1.1.故障等级划分 8114.2.1.2.服务响应承诺 8114.3.服务目标 8214.4.服务策略 8214.5.服务方式 8315.培训保障方案 8515.1.培训承诺 8515.2.培训目标和内容 8615.2.1.培训需求 8615.2.2.培训目标 8615.3.培训类别 8715.4.培训课程 8815.5.培训方式 88技术方案总体设计总体设计原则1、实用性原则系统建设中,兼顾实用性、可靠性、安全性、先进性、可扩充性,在满足功能要求的前提下,尽可能降低建设成本和运行成本。在系统建设特别是应用系统建设中,采用平台化、组件化的思想,充分利用成熟的应用支撑平台及中间件技术,分层实现,减少系统建设和维护工作量,提高系统的整体质量和效率,节省投资,应对变革。2、有效性与扩展性原则在多个层次的建设任务和建设阶段划分过程中,应充分体现阶段建设的有效性,尽量先满足具备条件的建设需求,将条件不成熟的建设任务后置,以免返工;建设过程应遵循一个时期内的有效性,够用、好用即可,避免在有限的时间内无限地扩张建设范围;同时在有效的基础上应考虑未来一定时期内的扩展性,减少后期投入。3、采用灵活的平台样式,页面中栏目能够灵活摆放,栏目能够灵活定义,风格样式能够灵活选择。4、平台能够适应一定的需求变化,能快速响应信息需求和功能需求的变化。5、操作简便,后台管理功能设计合理;具备良好的导航能力。总体设计思路采用统一顶层设计方法顶层设计方法的含义顶层设计方法主要是用系统论的方法,对考试院信息系统建设的各个方面、各个层次、各种参与力量、各种正面的促进因素和负面的限制因素进行统筹考虑,理解和分析影响系统建设的各种关系,从全局的视角出发,进行整体技术结构的设计,并做出各种管理和技术决策,提出体制和业务的改进建议。不论是业务处理还是内部管理,顶层设计对信息化建设的成效都起着至关重要的作用:在系统建设过程中,如果说没有统一的顶层设计、规划的话,那么各系统各自为政,软件、接口、体系标准都不一样,会导致互联互通实现不了,业务无法协同,内部办公效率低下。顶层设计中的”顶层”包含三个层次:第一层、从整体和全局出发。顶层设计的首要视角是要跳出局部环境的束缚和影响,站在全系统互联和全网通用的整体高度和全局视野,去分析决定应用系统建设过程中的基础、通用、平台型模块。比如说交易、服务资源目录体系,在应用互联互通的时代,交易、服务资源目录不但要供自己本系统、本单位使用,可能还要供相关联系统、外部单位使用,系统之间的接口必须统一兼容。如果交易、服务资源目录这个交易调用、服务共享的关键部件,在内容、格式、接口、协议上是彼此不同的,则违背了建设资源目录的初衷,必将导致形成新的孤立割裂、群雄并存的结局。第二层、从整体业务框架、顶层流程入手。顶层设计的重点是业务、是流程。应用系统开发失败的教训一再揭示正确全面描述用户需求,尽力满足用户需求的重要性,这里的用户需求,多半重点不在用户的操作需求,而是用户业务需求。顶层设计就是用信息工程的方法,从宏观上对业务需求进行收集、梳理和描述,把业务需求按层次、体系化呈现出来。顶层设计中的业务,不是进行业务决策,可是顶层设计的输出结果,将以丰富清晰的业务框架,帮助和推动业务决策,业务设计,业务改进和改革。第三层、从应用系统类型划分、整体架构规划入手。结合业务框架、顶层流程,规划合理的应用系统类型划分、整体架构规划,是顶层设计在应用系统设计过程中技术层面关心的主要问题。规划合理的应用系统类型划分,可确保基于业务框架的系统功能切分的合理性。可避免后续重复的系统建设,业务功能建设;整体架构规划可确保各类应用系统的建设在技术统一、平台统一、流程一致、方法一致的基础上实现系统之间功能接口、数据接口的一致性。顶层设计对象业务和技术,正是顶层设计的两大范畴。顶层设计中所指的业务,不但包括业务职能、业务结构、业务流程,还要包括业务体制、业务法律法规、业务模式、业务布局等事情。顶层设计中所指的技术,主要是从全局和整体出发,对技术战略、技术框架和技术标准的分析和定义,还包括为了减少重复建设,增加资源(业务需求分析、数据模型、软件模块、系统组件设计素材等等)重用性,以模块化服务的形式,来定义所有的应用系统。进行顶层设计,就是围绕着系统建设中上述业务和技术的种种问题,用系统规范的科学理论方法,描述业务和技术的状态,理清业务和技术中的各种关系,确定建设目标,选择和制定实现目标的路径和战略战术,从信息化的”今天”走向信息化的”明天”。采用成熟快速开发平台在本方案中,我们将采用IBM强大、成熟的开发应用平台,利用平台提供的应用支撑框架,如页面布局管理、工作流引擎、数据交换、页面流转、事务管理等,以及大量成熟业务、技术构件,如组织机构、用户权限、系统监控等,能够快速搭建各类业务应用,有效降低应用系统开发的进度风险和质量风险。界面设计原则用户原则访问界面设计首先要确立涉众用户类型,经过划分不同层次的用户类型,分析其不同需求,从多方面加以设计实现,提供用户自定义界面服务功能。简洁性原则界面反映的信息量要求最小,界面设计要尽量减少用户记忆负担,采用有助于记忆的设计方案,使用户操作更容易短期上手。易用原则软件界面设计要直观、对用户透明,最终用户接触软件后对界面上对应的功能一目了然,便于用户的理解、学习、掌握,不需要专业培训就能够方便使用系统。友好性原则人机界面友好,具有很强的在线帮助功能,方便操作和维护。要对用户的操作命令做出反应,帮助用户处理问题,提供智能业务提醒功能,辅助业务流程工作。系统要设计有恢复出错现场的能力,在系统内部处理工作要有提示,尽量把主动权让给用户。一致性原则界面风格统一设计、统一实现。使操作界面清晰,美观,干净,直观,前后操作连贯。在界面设计中应该保持界面的一致性,确立界面设计标准。包括显示信息、错误提示、快捷方式、页面布局、交互方式等标准,使系统风格始终保持一致。技术架构基于本文前面章节所述设计原则,按层次化思路,系统技术架构的层次结构如下图所示:系统技术架构由界面访问层、业务应用层、应用支撑层、数据资源层、系统设施层、网络通信层和支撑体系七个层次构成。其中,支撑体系又分为标准规范体系、安全保障体系和运维管理体系。OS／390系统OS／390技术特点OS／390操作系统是IBM公司最引以为豪的系统软件,它秉承和扩展了MVS的传统强势,是一个具有整合性功能的集成企业服务器操作系统。它将开放的通讯服务器、分布式数据和文件服务、并行复合系统支持、面向对象程序设计、DCE以及开放应用程序接口集成为一个产品,为用户提供了一个集成化的、具有可扩充性的系统。在体系结构上基于之前的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服务等功能。信用卡系统结构银行的信用卡系统业务负载较高,峰值交易量巨大,且对数据的存储、安全性与处理速度有较高的要求。基于OS／390的上述技术特点和优势,提出了一种基于OS／390大型机平台的银行信用卡系统模型,这里介绍其总体结构和技术特征。1.2．1总体业务结构模型。(1)总体业务结构模型。持卡人、收单银行、发卡银行和卡片组织之间的关系如下:申请人先向发卡银行申请信用卡,发卡银行按一定策略对申请者的信用状况进行评估,对符合条件的申请人核发信用卡。持卡人取得信用卡后即可到特约商店进行消费,每笔消费交易之前,特约商店会发起授权请求,经过信用卡国际组织授权清算网络向发卡银行请求授权,发卡银行根据卡片的信用状况决定是否给与授权,并将结果反馈给特约商店。特约商店取得授权后,即可为持卡人提供相应服务,持卡人要对消费行为及金额进行确认。之后,特约商店会依照消费金额向收单银行请款,收单银行会将钱先付给特约商店,再经过信用卡国际组织的清算网络向发卡银行请求清算,发卡银行确认后,将钱付给收单银行,并将消费金额计人持卡人帐户。当持卡人账单日到时,经过计算机系统将持卡人本月全部交易金额进行汇总,打印账单给持卡人,要求缴款。持卡人收到账单后,经确认无误,经过发卡银行的缴款通路缴纳消费款项。当有争议发生时,会依照授权码、消费签单,进行调单扣款作业处理。若持卡人在规定时间内未按要求交清所欠款项,发卡银行要对持卡人进行催收作业及一系列后续处理。在信用卡使用的整个循环中,发卡银行的计算机系统要完成征信发卡、授权、帐务帐单、催收调扣等主要模块的功能。具体业务流程如图1所示。图1总体业务结构模型图(2)总体系统架构。信用卡业务整体需求的特殊性决定了其计算机系统架构的复杂性。授权请求交易过程必须在线及时处理,同时持卡人会在全球各地、任何时刻进行刷卡消费活动,能否及时快速对如此大量、密集、不间断的授权交易请求作出准确、高效的响应,是衡量发卡银行计算机系统响应处理能力的重要指标同时,在计算机系统出现故障和异常时继续保证授权交易的正常进行是必须解决的关键问题。在后续请款、清算、帐务账单、催收和调扣处理过程中,系统中要存储大量关键数据,以供应用系统结合业务处理逻辑对数据进行加工处理,为银行提供各种需要的结果。如何管理好这些海量数据的存储和加工,在时空效率上满足业务要求,一直是计算机系统处理能力的瓶颈。针对上述问题,结合最新ES9000系列大型机技术发展的成果,在OS／390操作平台下设计新的计算机应用系统的整体体系架构如图2所示图2总体系统架构图在图2中,数据处理服务器采用IBMES／9000大型机,应用系统中大量业务数据的存储和加工处理、数据完整性与安全性由OS／390下的VSAM文件系统管理,各交易通路的数据获取及维护请求经过OS／390下的在线交易处理中间件CICS技术实现。联机前置处理服务器采用HP公司的TANDEM机,完成OLTP前置处理和备援功能,当ES／9000主机进行批量作业处理和有故障时完成代行功能,处理授权交易请求。各交易通路有自己的管理中心,经过各自的前置系统连接各种终端设备,再将业务进行处理、转发和传送。NETBANKSERVER、CALLCENIER和D0WNL0ADSERVER完成网络银行、电话银行及其它各种交易通路数据格式的转换及可靠连接传输功能。与VISA和MASTER国际组织之间的信息交互由VAPSERVER和MIPSERVER承担,AS／400的交换网络承担连外通路的收单功能,系统中对各业务关键节点进行双备份,比如信用卡中心的局域网等。可是,为了简明起见,没有画出。在上述架构中,整个系统既能集中管理信用卡业务的海量数据,同时又能对各交易通路的在线服务请求作出快速、准确的响应,最大程度地满足了信用卡业务整体需求。需求分析总体目标在信用卡系统中,针对信用卡业务的特点,企业提出能够经过网上单笔或批量两种方式对本企业账户下属的所有职员的信用卡进行报销款项转账业务并能够完成本企业账户下属的所有职员的信用卡快速申请和授信额度的灵活变更等信用卡辅助使用功能。经过对以上企业提出的需求进行分析,设计信用系统是应主要实现以下几方面的功能:>系统的主旨是面向重点企业客户,用户经过Intemet接入。>支持企业付款的单笔录入、批量导入,使系统更灵活,可用性更强>实现合笔从企业对公账户扣款,并逐笔往相应的信用卡中入账,即合笔扣账,逐笔入账。>实现根据不同企业的性质要求灵活定制企业端的复核和授权方式。>为实现及时完成企业报账划款的要求,必提高系统的安全性,实效性,信用卡系统要实现联机会计业务,即联机的会计扣账和冲账业务。>经过第三方CA产品安全保障对企业身份验证及付款指令的加密传输。>将原来分行与支行间资金的手工清算变为分行与支行间逐笔实施清算,将所有企业的对公账户扣款直接划归在分行卡部信用卡专户中,以完成逐笔入个人信用卡账户的功能。>实现当批量报账中存在异常卡的反馈和后续处理。>实现在网信用卡业务的5×8小时的联机服务。>实现信用卡账务系统批量接口,批量完成逐笔入账,提高处理效率。>银行处理端规范业务操作,相关传票、分录、特种转账传票由系统自动生成借口文件传到OnDemand报表系统中,减少手工操作风险。>提供系统的银行管理端,完成客户资料维护以及企业证书的管理。>提供多种方式的查询,以方便企业的管理和银行的管理。信用卡系统业务需求分析2.2.1信用卡快速申请1．业务描述是指客户经过网上信用系统向银行端发送申请办理信用卡的电子信息,银行对电子信息进行下载处理后,经过申请处理、审批、录入和开户等流程完成制卡手续,待领卡时补齐申请原件的业务处理。2．处理方式(1)由公司指定人员在信用卡系统填制信用卡电子申请表,要素包括:姓名、性别、身份证号码、家庭地址、部门名称、联系电话、账单地址等字段。(2)填妥后,附上申请人身份证扫描件发送至主管进行审批,审批后,回传至经办。由经办将审批后的申请表和身份证扫描件发送至银行端。(3)银行接收申请件后办理审批和制卡手续。(4)领卡时补齐申请原件。2.2.2卡资料及授权额度等信息变更1．业务描述是指客户经过信用卡系统提交授信额度的增加与修改、公司基本资料的修改、账单地址的变更等信息,银行接收客户提交的申请信息进行下载打印,并视作为有效申请,按正常流程进行处理的业务操作。2．处理方式(1)由公司指定人员在信用卡系统填写授信额度、持卡人基本资料和账单地址变更申请单。(2)填妥后,将<额度申请表>发送至主管进行核批,核批后,回传至经办。由经办将核批后的申请单发送至银行端(其它变更信息不需复核)。(3)银行接收申请信息后,将下载打印件直接作为申请原件,同时办理相关变更手续。2.2.3 多元化的查询1．回单查询输入日期及当日的报账批号即可查询当天此批号报账业务的银行处理情况,如果当天银行回单中有错误记录,则缺省显示出来,方便企业及时掌握报账处理情况广采取相应的措施。也能够根据日期和卡号查询某一张公务卡报销处理的情况。2．综合查询提供一个全面的查询功能。可能多选择的组合模糊查询,更方便企业的使用。强化了网上公务卡的企业财务的管理功能。系统安全需求对处理不同业务的企业端操作人员应根据不同的级别和操作权限对身份进行验证(登录财务中心系统必须持有CA认证证书,该证书应达到相应技术安全认证标准),保证交易安全和身份认证的有效性和合法性。一、系统登录控制与管理1．安全证书验证用户登录网上公务卡系统,必须经过安全和身份验证。2．签入系统经过用户名和密码登录系统。二、企业端用户证书级别和权限限定1．经办权限(1)创立、修改报账文件和相关信息更改申请文件(2)能够发送经复核后的报账文件、客户基本资料修改申请和账单地址变更申请(3)不可对报账文件进行复核。(4)不可对复核批准后的文件进行修改。(5)不可发送未经复核的报账文件和授信额度修改申请文件。2．主管权限(1)只可对相关申请文件进行复核,不可对文件进行修改。(2)不能发送所有文件。3．出纳权限:只能发送报账文件。三、所有的交易数据需要加密传输相关技术IBM公司的SNA网络技术SNA (SystemsNetworkArchitecture)系统网络结构,是IBM公司开发的网络体系结构,是一组大型网络标准和协议,包含着IBM大型机网络环境中配置和管理系统资源的服务,SNA定义了大型机主机控制终端的集中体系结构,是IBM大型机和中型机的主要联网协议,在IBM主机环境中得到广泛的应用。SNA这个体系结构中,包括大型计算机系统(ES／9000、S／390等)、中型机计算机系统(AS／400)、3270终端和台式计算机,并有一个使这些系统与主机系统通信或系统间相互对等通信的策略。SNA定义了数据通信网络的逻辑架构,网络资源之间进行同步通信的协议,网络上传输的信息格式;描述了网络上控制网络资源,进行网络配置,传输信息等操作次序。SNA网络由物理部分(physicalcomponents)和软件部分(softwarecomponents)组成,其中软件部分有访问方式(ACF／VTAM),应用子系统(CICS,components)组成,其中软件部分有访问方式(ACF／VTAM),应用子系统(CICS,IMS),用户应用程序和网络控制程序(ACF／NCP)。SNA的硬件部件和运行在其上的软件称为”节点(node)”,它们之间用数据链路(datalinks)互连。网络上的节点是端点或网络上的连结点。SNA设计的主要目的是端到端的通信,以及让用户应用程序远离复杂的数据通信系统,使用户感觉到数据通信系统的透明性。端用户一般是一台终端或者是主机上的应用程序。SNA网络就是为端用户提供相互之间通信的服务。SNA中被数据链路连接起来的物理部分(SNAphysicalcomponents)称之为SNA节点(SNAnode)。SNA提供一种以主机为中心的通信架构,定义了一些逻辑部件以实现这些功能。LU(109icalunit)用来处理端到端的通信;PU(physicalunit)是在SNA节点上用来管理物理资源的;SSCP(systemservicescontrolpoim)作为网络中访问控制的中心;DLC(datalinkcontr01)用来管理数据传输的链路;PC(pathcontr01)用来处理数据在SNA网络中传输的路由。IBMWebSphereMQSeries中间件在网上公务卡系统的设计与实现中,需要从位于防火墙以外的网上公务卡企业端WEB服务器发送业务数据包到位于两层防火墙以内网上公务卡银行端服务器上,在此传输过程中,由于网络状况等因素使得业务数据包的传输可靠性、高效率和安全性难以得到有效的保障,因此,在实现中我们使用了IBMWebSphereMQSeries中间件作为工具对报文进行传输,有效地实现了远程数据包的可靠传送。MQSeries是IBM的商业通讯中间件(CommercialMessagingMiddleware)。MQSeries提供一个具有工业标准,安全,可靠的信息传输系统。它的功能是控制和管理一个集成的商业应用,使得组成这个商业应用的多个分支程序(模块)之间经过传递消息完成整个工作流程。MQSeries基本由一个消息传输系统和一个应用程序接口组成,其资源是消息和队YlJ(MessagingandQueuing)IBMWebSphereMQSeries中间件有着以下四方面的优点:1．统一接口,跨越IBM和非IBM平台。简单的PUT和GET动词在MQSeries支持20种mM和非IBM平台上完全相同。使得MQSeries提供了这样的特性:目标应用程序位置的透明性(targetapplicationlocationtransparency)。对于一个应用程序的开发者,她需要知道的全部只是队列的名字,这个队列与一个特定的服务有关,而与系统的平台或系统在什么地方无关。2．使开发人员避开网络的复杂性。因为MQSeries负责处理所有的通讯,开发人员不必编写任何通讯方面的程序。而且编程和调试非常简单和直接,不需要具体的系统和通讯方面的知识。特别在C／S模式的应用时,开发人员能够集中精力在与业务有关的客户端和服务器端的应用,而不必考虑操作系统和通讯,特别是底层的网络通讯,节省大约50％到75％的通讯编程工作。3．处理不依赖时间的限制。意思是说在信息创立和发送时,信息的接收方或到接收方的通道不需要激活。不受时间的限制增加了处理的灵活性,允许事务处理在它们想做或有时间做时,彼此通讯程序能够运行在不同的时间。这样程序的运行是独立的,如果逻辑允许,它们不必等待其它程序的应答而继续工作,利用这种异步处理功能,能够更有效的使用资源,更灵活的处理模式,应用处理能够是独立的,并行的,重叠的,从而改进用户服务。4．给分布式处理提供的强健的中间件。包括逻辑工作单元支持(109icalunitofwork),备份和恢复机制,大信息传递和高性能等特点。其中最重要的是确保信息传输,意思是一旦MQSeries接受一个信息传输的任务,会确保信息被传送到目标平台。信息的传输是一次且仅一次．另外,强健的中间件机制保证业务数据一致性,并可在系统发生故障时,及时恢复,业务不会受到影响。CICS中间件CICS(CustomerInformationControlSystem)客户信息控制系统是IBM公司的联机事务处理系统,作为一种交易中间件被广泛应用于当今信息产业领域的各种事务处理环境中。交易中间件也称为事物处理中间件,是专门针对联机交易处理系统而设计的,它是操作系统和应用程序之间的一层软件平台,主要为上层的应用程序提供一致的应用编程接口,即提供透明访问操作系统的功能和系统管理辅助工具等。CICS作为一个强有力的联机事务处理中间件,具有商业级事务管理器要求的整合性、可恢复性、安全性和可用性,具有跨平台的广泛的可操作性,提供跨平台的API,形成可移植的应用和开发技术。在联机事物处理系统中,CICS经过标准的)【A接口同数据库之间进行数据通讯,完整的体系结构保证了CICS服务器与数据库之间连接的灵活性,并保证着事物完整性和数据一致性】。CICS最初来源于主机环境,现在运行于很多IBM和非IBM平台和各种不同的网络环境(从几台微机到几千个终端)。在任何一个应用CICS的硬件或软件平台上,程序员能够经过CICS应用程序接口(API)进行程序设计调用CICS应用,而且能够在不同的系统平台上进行移植。CICS家族的每一个产品都有良好的继承性,兼容家族中其它产品,而且能够经过网络进行彼此远程调用。在本系统的设计过程中,网上公务卡银行端与会计主机之间即采用了CICS中间件来保证交易的一致性。系统的详细设计与实现企业端与银行端的通讯实现一、IBMWebSphereMQSeries中间件的基本组成描述有以下几方面:1．队列管理器队列管理器是MQ系统中最上层的一个概念,由它为我们提供基于队列的消息服务。2．消息在MQ中,我们把应用程序交由MQ传输的数据定义为消息,我们能够定义消息的内容并对消息进行广义的理解,比如:用户的各种类型的数据文件,某个应用向其它应用发出的处理请求等都能够作为消息。消息有两部分组成:消息描述符(MessageDescription或MessageHeader),描述消息的特征,如:消息的优先级、生命周期、消息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的服务器和服务器之间传输消息的,需要强调指出的是,该通道是单向的,它又有发送(sender),接收(receive),请求者(requestor),服务者(server)等不同类型,供用户在不同情况下使用。MQI通道是MQClient和MQServer之间通讯和传输消息用的,与消息通道不同,它的传输是双向的。群集(Cluster)通道是位于同一个MQ群集内部的队列管理器之间通讯使用的。三、IBMWebSphereMQSeries的工作原理IBMWebSphereMQSeries的工作原理如图4.1所示:图4-1IBMWebSphereMQSeries的工作原理首先来看本地通讯的情况,应用程序A和应用程序B运行于同一系统A,它们之间能够借助消息队列技术进行彼此的通讯:应用程序A向队列1发送一条信息,而当应用程序B需要时就能够得到该信息。其次是远程通讯的情况,如果信息传输的目标改为在系统B上的应用程序C,这种变化不会对应用程序A产生影响,应用程序A向队列2发送一条信息,系统A的MQ发现Q2所指向的目的队列实际上位于系统B,它将信息放到本地的一个特殊队列一传输队YU(TransmissionQueue)。我们建立一条从系统A到系统B的消息通道,消息通道代理将从传输队列中读取消息,并传递这条信息到系统B,然后等待确认。只有MQ接到系统B成功收到信息的确认之后,它才从传输队列中真正将该信息删除。如果通讯线路不通,或系统B不在运行,信息会留在传输队列中,直到被成功地传送到目的地。这是MQ最基本而最重要的技术——确保信息传输,而且是一次且仅一次(once．and．only-once)的传递。MQ提供了用于应用集成的松耦合的连接方法,因为共享信息的应用不需要知道彼此物理位置(网络地址);不需要知道彼此间是怎样建立通信:不需要同时处于运行状态;不需要在同样的操作系统或网络环境下运行。四、MQ的架构网上公务卡企业端服务器与网上公务卡银行端的处理服务器之间的通讯是经过中间件IBMWebSphereMQSeries实现的在企业处理服务器中,交易报文的转发是其最重要的功能,在银行处理服务器的通讯中,我们使用了IBMWebSphereMQSeries消息中间件来对报文进行传输,下面我们将对MQ的配置、定义以及程序的调用加以详细的讨论。在企业处理服务器和银行处理服务器,我们分别定义了本地队列和远程队列,分别用于存储远程发送来的交易报文以及将交易报文发送至远程的队列当中。例如:我们在企业处理服务器中建立了远程队列RQ01用于将企业提交的报账数据整理并组包后经过CH2l通道发送到银行处理服务器的本地队列LQ01中。经过银行处理服务器处理后,将处理结果从远程队列RQ01经过CHl2通道发送到企业处理服务器的LQ01队列中。图4.2说明了MQ队列的具体结构图。图4-2MQ具体结构图运行环境软件平台操作系统:OS/390应用框架:RPG数据库:DB2浏览器:MicrosoftInternetExplorer6.0及以上开发工具说明整个平台的开发将采用IBM核心的OS/400RPG银行系统开发工具,并使用最新的版本,使整个平台具备先进的应用环境。项目实施及服务方案

项目组织与管理本章主要阐述了IBM银行信用卡系统项目的干系人、参与整个项目的各方人员的组织结构设置及职能;针对本项目,佰钧成的项目组织结构及岗位职能;以及佰钧成的项目质量保证体系的介绍。项目干系人分析基于我们对IBM银行信用卡系统项目的理解,我们将以合作伙伴的角色加入到整个项目中。从规划设计、实施、运维等多环节全方位提供信息化建设服务。从这个基础出发,我们把本项目涉及到干系人分成几类,如下表所示:干系人名称主要职责项目建设方(用户方):IBM提出并确认项目需求;监督工程项目进展情况;审查和验收项目工作成果;项目承建商:武汉佰钧成技术有限责任公司承建IBM银行信用卡系统项目;对建设方案中的系统进行设计、开发、实施;按照总体技术方案和详细技术方案的要求完成系统的开发测试工作;协助招标人、项目监理的验收评审工作;提供系统运行维护服务;提供培训工作;项目组织结构根据本项目”多个组织,一个团队;同一平台,全面沟通”的原则,合理、科学的项目组织结构对于本项目的有效实施将起到事半功倍的效果。为此,建议建立如下图所示的项目组织结构:武汉佰钧成技术有限责任公司武汉佰钧成技术有限责任公司项目领导小组项目经理项目开发实施小组IBMGDC注:箭头表示汇报路径。角色职责人员要求项目领导小组项目的最高决策机构。对项目的战略方向、IT规划、重大事件进行决策。负责有效的将决策信息传达给项目管理小组,监督、管理决策意见的执行结果。批准项目实施规范,协调内部资源。项目领导小组将进行不定期会晤。由IBM银行信用卡系统项目管理领导团队、武汉佰钧成技术有限责任公司项目管理领导人员联合组成。项目领导小组人员,在所属机构内,必须具有项目总体规划、决策的相应权力。项目经理在整个项目实施期间的担任项目管理和行政管理的工作;根据项目需要,协调各方关系;贯彻、落实项目领导小组的决策意见,并有效的监督、管理其执行状态;定期向项目领导小组汇报项目执行情况和总体执行状态。由武汉佰钧成技术有限责任公司相关人员担任。项目开发实施小组依据有效的责任范围工作定义进行具体的项目任务实施,接受管理层的直接管理,定期向管理层汇报工作。根据项目需要,由IBM银行信用卡系统、武汉佰钧成技术有限责任公司的相关人员联合组成。主要人员投入角色姓名工龄职务项目领导小组李磊15高管江龙13研发经理项目经理许卫国15项目经理系统架构师张岩13高级工程师数据库设计师王辉10高级工程师代码设计师於艳5高级工程师代码设计师朱婧5产品技术经理代码设计师郝建军2软件工程师代码设计师李兴彬2软件工程师质量保证员陈新3QA配置管理员洪子娟3CM美工朱亚5专职美工测试经理刘博5测试经理测试工程师邓育飞2测试工程师测试工程师罗莲2测试工程师测试工程师杨丽2测试工程师支持组-客户经理余海霞6客户经理培训工程师邵宁7高级工程师维护组刘流9软件工程师佰钧成的项目服务管理体系结构佰钧成主要从事金融、信用、政府行业信息化建设方面的软件开发、系统集成、软件外包、咨询服务等业务。经过多年的信息化服务,公司积累了丰富的应用建设经验并形成了完善的技术服务体系和服务管理体系。公司级管理服务体系佰钧成基于多年政府信息化建设的服务历程,不断的吸取国内外先进的IT服务管理理念,构建了IT服务管理体系结构。佰钧成的质量保证体系和项目方法论作为行业应用服务团队处理问题、事故、变更、配置等的行为标准和规范体系;项目管理团队、系统集成团队、研发团队和基础职能部门为应用服务团队的服务提供级别管理、财务管理、持续性、可用性管理等服务质量提供了有力保证。佰钧成的决策体系保证了授权、决策渠道的畅通,使得服务管理的内部决策过程快捷、高效。项目级服务管理体系结构信息化建设的主要工作除了依托公司的组织结构和管理体系,更重要的是具体实施信息化建设的项目级服务管理系统,这将直接关系到政府信息化建设的实施效果。佰钧成建立了完善并有效的项目组组织结构和服务体系。项目组内部岗位职责依据项目情况确定。一般包括:项目领导小组(项目总监):分项目情况确定,小型项目中一般由部门(副)经理、咨询专家、技术经理担任;大中型项目或战略项目中一般由副总或行业总监、技术总监、部门(副)经理、咨询专家、高级技术经理担任。项目经理:由部门级或公司级管理者担任项目经理。客户经理:中小型项目由部门销售团队负责人指定。一般由客户经理担任。大项目或战略项目由公司项目管理委员会确定。架构师:根据项目规模需要设立。由项目经理提名,软件开发中心负责人批准。技术经理:由项目经理提名,软件中心负责人批准。一般由技术经理或工程师担任,对项目技术实现负责,协助架构师进行总休设计、概要设计,主导详细设计。开发经理:由项目经理提名,软件中心负责人批准。一般由公司高级工程师担任,主导项目编码工作。需求经理:由项目经理提名,软件中心负责人批准。一般由公司咨询顾问和业务经理担任,对项目业务需求负责。项目工程师(含开发、测试、维护):由项目经理提名,软件中心批准。一般由工程师担任。咨询顾问:由项目经理提名,项目管理办公室批准。一般由工程师担任。注:上述为项目组的标准配置,根据项目规模的大小,上述岗位能够部分或全部合并。对于本项目,虽然规模不大,但鉴于项目的战略地位,我公司将设立较为全面的组织结构,并配备专职人员。项目实施计划本章阐述了IBM银行信用卡系统评论网站项目工程实施的阶段划分、总体实施计划,并详细介绍了各阶段的工作计划及工作内容。项目阶段划分基于佰钧成软件服务最佳实践模型,依据我们对本项目的理解,定义主要项目阶段划分如下表所示:编号阶段名称阶段主要工作描述1准备阶段完成项目启动准备工作,主要包括成立项目组织、项目人员的确定、确定项目计划、对项目实施任务的确认、合同的签订、项目实施环境、工具等的准备。2需求阶段完成需求调研、需求分析工作,为便于与客户方的交流,需求开发系统原型,最终形成需求调研报告和需求规格说明书,由公司方和客户方相关专家完成需求评审。3设计阶段完成系统的总体设计、详细设计、数据库设计工作、单元测试等测试计划、用例的编制,在系统原型基础上进行进一步的设计、开发,完成最终的设计成果的评审。4开发阶段以系统设计为基础完成应用软件的编码开发和单元测试工作,另外还有集成测试计划及用例的编制等其它工作。5集成测试阶段完成应用软件的集成测试工作并进行评审。6试运行、上线及终验阶段完成系统的试运行工作,对试运行期间发现的问题进行进一步的修改、完善和测试;同时完成系统上线过渡的准备工作,包括数据、软、硬件环境、人员培训等。在试运行结果符合项目要求后对项目进行最终验收。同时再上线试运行阶段,将会沿用原来系统中的数据,所做工作包括数据迁移。7运营维护阶段在系统验收后进入运营维护阶段,由技术支持及服务人员对系统运行提供技术支持服务,对系统业务变化进行修改完善,保证系统正常使用。8贯穿各阶段的其它任务包括项目建设中的其它一些任务,这些任务不是在哪个特定阶段完成,而是伴随整个项目实施的过程进行,主要包括数据资源的清理和规划设计、系统集成、培训、项目管理等。项目总体计划依据我们对招标方的实施进度要求的理解,制定了本项目的总体进度计划。项目自合同签订之日启动,我们对本项目计划总体安排如下:第1月第2-4月第5月第6月准备阶段需求阶段设计阶段开发阶段集成测试阶段准备阶段本阶段主要进行建立项目组织、建立项目管理体制、优化项目计划、工作任务定义、开发环境准备及环境搭建、招标需求分析确认等工作。建立项目组织:我公司提出项目组织计划,与用户就本项目的项目组织进行沟通交流,确定项目组织结构及相应人员岗位,明确项目组中每个人的责任,确定项目核心成员。建立项目管理体制:与用户就本项目的项目管理体制进行讨论,最终形成项目管理体制。优化项目计划:针对实际情况对项目计划进行优化,编写项目进度计划和预算。招标书需求分析确认:再次确认用户在招标文件中提出的需求。开发环境准备及环境搭建:准备项目开发工作场所,包括软、硬件环境,就本项目采用的各项技术,搭建开发环境。编写项目的工作说明书,对项目实施的项目范围、项目阶段、工作方法、相关各方的责任分工、各阶段的交付物、阶段完成里程碑、沟通制度等进行明确规定,同时编写质量保证计划,编写配置管理计划,以及项目实施的有关规章制度等;本阶段要实现的里程碑是:签订商务合同和工作说明书。本阶段承建方的主要参与人员有售前人员、需求分析人员、架构师、项目管理人员(含质量、配置人员)。客户方主要参与人员为项目组织人员。需求阶段本阶段主要内容为需求调研和需求分析,用户培训、初步用户手册的编制等工作内容。需求调研和需求分析:公司组织资深的系统分析人员对用户需求进行进一步的分析,与用户不断沟通、交流,确认已经明确的需求内容,经过不断调研、确认,最终形成需求规格说明书,完成由用户组织的专家进行评审。初步用户手册的编制:根据需求内容,编制初步用户手册。需求评审:针对需求规格说明书进行用户的需求评审。本阶段要实现的里程碑是:签署需求规格说明书。本阶段承建方的主要参与人员有项目管理人员、需求分析人员、架构师、开发人员。本期客户方主要参与人员为项目组织成员、相关业务部门的部门主管及业务骨干、科技部门相关人员。设计阶段本阶段主要内容为系统的总体设计和详细设计、数据库设计、测试方案的设计、用户培训等工作内容。总体设计:提出设计的方法及该阶段的工作进度安排,并得到招标方确认;编制总体设计方案;编制测试环境建设方案;编制系统上线试运行至系统正式上线期间的时间安排;提供对项目应用系统设计风险的详细评估。详细设计:完成应用系统软件功能模块的详细设计。数据库设计:完成数据库系统的详细设计,包括数据库结构、表结构、数据字典等的编制。测试方案的设计:系统详细设计,完成测试大纲、测试计划、测试用例的详细设计,使得在下一阶段应用系统开发完成后。完成系统设计的评审;本阶段要实现的里程碑是:评审经过项目设计方案(包括数据库设计方案)。本阶段承建方的主要参与人员有项目管理人员、需求分析人员、架构师、开发人员、测试人员。本期客户方主要参与人员为项目组织成员、科技部门相关人员、相关业务部门的业务骨干。开发阶段本阶段主要完成应用软件系统十个模块的开发的编码与单元测试工作。包括配置研发及测试人员、配置开发及测试设备、进行系统编码、并进行测试方案的评审。本阶段要实现的里程碑是:完成软件的开发评审。本期项目承建方主要参与人员为需求分析人员、软件架构设计人员、软件开发人员、软件测试人员、配置管理人员、项目管理人员。本期客户方主要参与人员为项目组织成员、技术人员及相关业务部门的业务骨干。集成测试阶段本阶段主要完成应用软件系统的集成测试工作,测试工作包括单元测试、功能测试、集成测试、性能测试、安全测试、健壮测试、界面测试、安装测试、文档测试工作,并编写相应的测试报告,同时编写系统使用手册。本阶段要实现的里程碑是:经过系统集成测试评审。本期项目承建方主要参与人员为需求分析人员、软件架构设计人员、软件开发人员、软件测试人员、配置管理人员、项目管理人员。本期客户方主要参与人员为项目组织成员、技术人员及相关业务部门的业务骨干。试运行、上线及终验阶段本阶段主要完成的工作为试运行的准备以及对在试运行过程终发现问题的修改工作,用户培训工作,数据迁移,系统过渡,试运行工作以及系统切换后的正式上线和终验工作。试运行过程发现问题,要确定工作方案,进行问题解决。用户培训:完成此阶段对用户的培训工作。数据迁移:完成应用系统的数据迁移工作。系统过渡:完成系统过渡工作。试运行:完成系统试运行工作。在完成系统上线稳定运行,进行项目终验。本阶段要实现的里程碑是:完成系统试运行,签署系统终验报告。本期客户方主要参与人员为项目管理人员、项目组织成员、系统集成人员、培训人员、技术人员、配置管理人员、各业务部门的领导和业务骨干人员。运营维护阶段本阶段是从项目终验合格后开始进行为期3年的质保时间。贯穿各阶段的其它任务用户培训:此项工作从需求分析开始,到终验前结束,完成用户培训工作,培训内容包括操作人员培训、系统维护人员培训、管理人员培训。项目管理。项目管理工作从项目启动开始,持续到项目维护期结束,主要由我公司项目管理人员完成本项目实施的管理工作。项目成果和交付物根据项目实施的不同阶段,我公司项目组将向客户单位分批移交项目实施过程中生成的成果和各类技术文档、使用文档,结合本项目进度计划分阶段提交的成果和交付物如下表所示:阶段名称成果和交付物备注准备阶段需求分析需求规格说明书;系统设计概要设计说明书详细设计说明书数据库设计说明书系统开发编程规范模块开发卷宗系统源代码及执行码单元测试计划;单元测试报告;培训资料(教材);软件功能技术手册;集成测试集成测试计划;集成测试用例;集成测试报告(含压力测试报告);试运行、上线和终验程序清单安装维护手册用户操作手册程序源代码运营维护技术维护手册故障应急处理手册;项目风险计划项目风险分析尽早进行风险分析,能够减少项目实行过程中的不确定性。它不但使各层次的项目管理者建立风险意识,重视风险问题,防范于未然,而且在各个阶段、各个方面实施有效的风险控制,形成一个前后连贯的管理过程。作为面对项目风险的有效手段,全面风险管理强调风险的事先分析与评价,风险因素分析是确定一个项目的风险范围,并将这些风险因素逐一列出以作为全面风险管理的对象。罗列风险因素一般要从多角度、多方位进行,形成对项目系统的全方位的透视,我们一般对风险因素的分析经过以下方面进行分析:1、首先,按项目系统要素进行分析。这主要有四个方面的系统要素风险:项目环境要素风险:最常见的有政治风险、法律风险、经济风险、自然条件、社会风险等;项目系统结构风险:如以项目单元为分析对象,在实施以及运行的过程中可能遇到的技术问题,人工、材料、机械、费用消耗的增加等各种障碍和异常情况等;这是IT项目中最主要的风险。项目的行为主体产生的风险:如承包商(分包商、供应商)技术及管理能力不足,不能保证安全质量,无法按时交工等产生的风险;项目管理者的能力、职业道德、公正性差等产生的风险;其它方面的风险:如外围主体(政府部门、相关单位)等产生的风险。2、其次,按风险对目标的影响分析。这是按照项目的目标系统结构进行分析的,它体现的是风险作用的结果,它包括以下几个方面的风险:工期风险,如造成局部的(工程活动、分项工程)或整个工程的工期延长,不能及时投产;费用风险,这包括财务风险、成本超支、投资追加、报价风险、收入减少等;质量风险,这包括工程等不能经过验收,工程试生产不合格、经过评价工程质量未达到标准或要求;生产能力风险,项目建成后达不到设计生产能力;市场风险,工程建成后达不到预期的经济目标,没有竞争力;法律责任风险,可能因此被起诉或承担相关法律的或合同的责任。3、再次,按管理的过程和要素分析。这个分析包括极其复杂的内容,但也常常是分析风险责任的主要依据,它主要包括:高层战略风险,如指导方针战略思想可能有错误而造成项目总体目标设计的错误等;环境调查和预测的风险;决策风险,如错误的选择,错误的投标决策、报价等;项目策划风险;技术设计风险;计划风险,如目标的错误理解,方案错误等;实施控制中的风险,如合同、供应、新技术新工艺、分包层、工程管理失误等方面的风险;运营管理的风险,如准备不足,无法正常运营,销售不畅等的影响。从总体上能够将该项目的风险分为宏观和微观两部分,宏观方面的风险指针对该项目的特点而使项目的实施具有的风险,微观风险则指在软件开发过程中会出现的风险。基于上述分析方法,针对本项目,我们识别如下项目风险:宏观风险分析从项目的整体规划上看,本项目作为一项IBM银行信用卡系统的一个信息化工程建设项目,其具有以下特点:应用系统建设涉及的业务内容多;项目工程进度时间要求短;涉及业务学科领域广,且部分信息化建设任务缺乏案例和成功经验可循;由于项目的这些特点,使项目的建设存在以下风险性:1、项目建设的统筹规划、协调实施方面的风险性这一风险属于项目管理的风险,主要体现为制定合理的项目计划、预算项目成本、资源配置、质量管理及项目管理技术选择等方面,由于项目的建设内容多,建设内容存在交叉与关联,因此使项目的建设不确定性、复杂性并存,带来项目统筹规划、协调实施的风险性。2、项目周期相对短造成的组织、实施方面的风险性组织风险中的一个重要的风险就是项目决策时所确定的项目范围、时间与费用之间的矛盾。此系统的应用软件开发任务多、工作量大,而项目工期相对短,这造成了项目范围和时间的矛盾,因此给如何合理地组织人力与资源,制定可行的项目进度计划带来了困难,形成了项目实施的一定风险。3、项目建设经验欠缺造成的实施风险性造成这一风险的主要因素为项目涉及业务学科领域广,且部分建设内容属IBM银行信用卡系统首创,欠缺先前案例及成功经验,使系统的建设无先例可循,需在建设中摸索,从而使项目的顺利实施在进度控制、技术实现等方面存在一定风险性。4、项目受不可控因素影响产生的风险性该项目受不可控因素的影响主要表现在以下几个方面:本项目的建设是一个新的业务需求,如电子登记簿的使用,复杂的监控标准,智能监控、预警,这些都要求各级系统使用者必须在深刻理解信息化的本质基础上给予高度关注和重视,提供充分的支持。本系统建设是一项知识密集的系统工程,项目管理不到位,缺少足够的经验,不严格按信息化建设规律办事是等都有可能加大本项目失败的风险。系统建设过程中如若缺乏一种有效的监督管理机制,将致使许多任务在质量、进度、投资等方面都无法得到很好的保证和控制,出了问题就互相推诿,项目中途下马或完工后难以达到预期建设目标。5、项目由于外部因素影响可能存在的风险性项目外部风险主要是指项目的政治、经济环境的变化,包括与项目相关的规章或标准的变化,组织中机构的变化,如机构合并、自然灾害等。这类风险对项目的影响和项目性质的关系较大。微观风险分析项目过程的每个阶段都存在着不同的风险,这些风险与该阶段的工作内容紧密相关。1、合同签约立项阶段可能存在的风险:项目宏观目标不清;项目范围不明确(范围太大太小都不能够);用户参与少或和用户沟通少;对业务了解不够;对需求了解不够;没有进行可行性研究。2、项目启动阶段可能存在的风险:项目具体目标不清;项目范围不够精确;用户参与不够;本项目的规划不够准确;3、项目计划阶段可能存在的风险:项目队伍缺乏经验,如缺乏有经验的项目经理;没有变更控制计划,以至于变更没有依据,该变更的不变,不该变的也变,这样得来的设计势必会失败或者偏离用户需求;仓促计划,可能带来进度方面的风险;漏项,由于设计人员的疏忽某个功能没有考虑进去;4、项目执行与控制阶段可能存在的风险设备环境没有具备好;计划错误带来的实施困难;项目团队实施能力差;项目范围改变(突然要增加或修改一些功能,需要重新考虑设计);项目进度改变(要求提前完成任务等);人员离开,在一个项目内软件开发工作有一定的连续性,需要移交和交接,有时人员离开对项目的影响会很大;开发团队内部沟通不够,导致程序员对系统设计的理解上有偏差;没有有效的备份方案;没有切实可行的验收计划;验收人员经验不足;5、收尾阶段可能存在的风险:质量差;客户不满意;设备没有按时到货,软件无法应用等;6、维护阶段可能存在风险:系统运行不稳定;客户人事变化;客户业务变化导致付款出现问题;在本项目中,上述微观风险皆在一定程度上存在,针对上述风险,我们在整体项目管理中,从组织结构、人员配备、计划管理、质量保证等诸多方面均进行了有针对性的准备,从而在一定程度上缓解上述风险,而且根据我公司的风险识别定义进行风险识别。主要风险识别及缓解措施由于项目的一次性和特殊性,在风险判别中无法根据历史数据或资料对项目风险做出准确估计,只能靠专家或决策人员根据自身经验和知识对项目风险做出主观估计,特别是在项目立项论证或研制的初期阶段更是如此。为对项目风险进行准确判别,有必要规定统一的级别描述标准。我们公司对技术风险、费用风险、进度风险、管理风险进行了如下级别描述,并针对本项目进行了如下风险识别:技术风险级别描述表技术风险风险级别本项目风险缓解措施成熟性现有的或局部重新设计低中等配备公司核心骨干参与项目主要部分重新设计,但技术可行中等技术可行的复杂设计或最新技术,某些研究已完成高复杂性简单设计或局部增加复杂性低中等经过设计原型解决复杂性有中等程度增加中等复杂性显著增加或极其复杂高相关性与现有系统、设施或相关的研制单位无关或进度取决于现有的系统设施或相关的研制单位低低不需要性能取决于现有系统性能、设施或相关的研制单位中等进度取决于新系统的进度、设施或相关的研制单位或性能取决于新系统的性能、设施或相关的研制单位高费用风险级别描述表费用风险风险级别本项目风险缓解措施任务要求明确性任务要求明确,使用方和承制方对任务有共同的理解低低不需要任务要求基本明确,某些细节上尚需进一步确定中等任务要求不明确,使用方可能不断提出新的要求或双方对任务要求有不同的理解高技术风险影响无高风险项目,中等风险项目不超过2个低低无高风险项目,中等风险项目超过3个中等有1个以上的高风险项目高进度风险影响无高风险项目,中等风险的进度指标不超过2个低低无高风险项目,但中等风险项目在3个以上中等有1个以上的高风险项目高成本预算准确性有充分的类似项目的历史数据可供参考,成本估算部门有足够可用的合格人员低低有足够可用的合格人员但仅有部分历史数据可供参考中等缺乏可用的合格人员且无类似项目的历史数据供参考高合同类型影响固定价格合同低低成本加奖励费用合同中等拨款性合同高合同报价影响与其它竞标单位的报价和预测成本基本相符低待定略低于其它竞标单位报价和预测成本中等报价显著低于其它竞标单位的报价和预测成本高进度风险级别描述 进度风险风险级别本项目风险缓解措施技术风险影响无高风险,中等风险项目不超过2个低低不需要无高风险,中等风险项目超过3个中等有1个以上的高风险项目高计划安排合理性计划切实可行且留有一定时间余度以防意外情况发生低中等经过集中封闭开发和对进度加强控制,根据情况增加资源等来缓解计划可靠,但对意外发生的问题未留有余度中等计划不可靠,不是根据每项研制工作的实际需要来安排时间,而是根据竞争的需要或上级命令来分配时间高资源充分性资源充分且可供使用低低不需要现有资源充分,但与其它项目之间有潜在的矛盾冲突,可能因某些预想不到的问题而影响进度中等现有资源不足或与其它项目之间存在严重的潜在冲突高项目人员经验参与该项目的人员在类似的项目中已积累了经验,有足够的知识储备可用于该项目低低不需要参与人员在类似的项目中已有一般性的经验,但在某些关键部门还缺乏有经验的人员中等参与人员普遍没有在类似项目中工作的经验,关键部门可用的有经验人员很少高管理风险级别描述管理风险风险级别本项目风险缓解措施领导素质影响领导者决策能力强,很有威望低低不需要领导者决策能力较强,威望一般中等领导者决策能力一般,同时也没什么威望高组织机构影响组织机构健全,各机构间配合密切、融洽,运作效率高低低组织机构基本完善,运作效率一般中等组织机构不完善,或虽完善但运作效率很低高计划条理性计划安排很有条理,且在关键项目上态度较为保守低低计划安排有序,但在计划安排上态度较激进中等计划安排没条理,或一般但态度很激进(冒险型)高研发人员素质研发人员整体素质高,且人员之间协作能力强低低研发人员整体素质较高,但人员之间协作能力一般中等人员整体素质一般,协作能力也一般高研发实力及条件实力雄厚、条件优越且得到大家一致公认低低实力和条件较好,能胜任项目的研究中等实力和条件一般,基本能胜任项目研究工作高各阶段的协调协调能力强,能作好各阶段的协调工作,应付突发事件能力强低低协调能力较强,正常情况下能保证各阶段的协调一致,应付突发事件的能力一般中等协调能力一般,应付突发事件的能力差高其它风险控制措施1、风险分配项目风险必须在项目参加者(包括投资者、业主、项目管理者、承包商、供应商等)之间进行合理的分配,只有每个参加者都有一定的风险责任,才有可能对项目管理和控制的积极性和创造性,只有合理的分配风险才能调动各方面的积极性,才能有项目的高效益。合理分配风险要依照以下几个原则进行:从工程整体效益的角度出发,最大限度地发挥各方面的积极性。项目参与各方如果都不承担任何风险,则她也就没有任何责任,当然也就没有控制的积极性,就不可能搞好工作。因此只有让各方承担相应的风险责任,经过风险的分配以加强责任心和积极性,达到能更好地计划与控制。其有效的做法应为合同管理的机制到位,并面向各个承包商和参与方的工程合同,应站在工程总体的高度上进行控制和实施,公平合理,责、权、利平衡。一是风险的责任和权力应是平衡的。有承担风险的责任,也要给承担者以控制和处理的权力,但如果已有某些权力,则同样也要承担相应的风险责任;二是风险与机会尽可能对等,对于风险的承担者应该同时享受风险控制获得的收益和机会收益,也只有这样才能使参与者勇于去承担风险;三是承担的可能性和合理性,承担者应该拥有预测、计划、控制的条件和可能性,有迅速采取控制风险措施的时间、信息等条件,只有这样,参与者才能理性地承担风险。2、风险对策任何项目都存在不同的风险,风险的承担者应对不同的风险有着不同的准备和对策,这应把它列入计划中的一部分,只有在项目的运营过程中,对产生的不同风险采取相应的风险对策,才能进行良好的风险控制,尽可能地减小风险可能产生的危害,以确保效益。一般的风险对策为:采取先进的技术措施和完善的组织措施,以减小风险产生的可能性和可能产生的影响。如选择有弹性的、抗风险能力强的技术方案,进行预先的技术模拟试验,采用可靠的保护和安全措施。对管理的项目选派得力的技术和管理人员,采取有效的管理组织形式,并在实施的过程中实行严密的控制,加强计划工作,抓紧阶段控制和中间决策等。3、实施中的全面风险控制工程实施中的风险控制贯穿于项目控制(进度、成本、质量、合同控制等)的全过程中,是项目控制中不可或缺的重要环节,也影响项目实施的最终结果。加强风险的预控和预警工作。在工程的实施过程中,要不断地收集和分析各种信息和动态,捕捉风险的前奏信号,以便更好地准备和采取有效的风险对策,以抗可能发生的风险。在风险发生时,及时采取措施以控制风险的影响,这是降低损失,防范风险的有效办法。在风险状态下,依然必须保证工程的顺利实施,如迅速恢复生产,按原计划保证完成预定的目标,防止工程中断和成本超支,唯有如此才能有机会对已发生和还可能发生的风险进行良好的控制,并争取获得风险的赔偿,如向保险单位、风险责任者提出索赔,以尽可能地减少风险的损失。项目测试与验收方案项目测试方案测试概述软件工程的测试是非常重要的一环,也是检验系统开发最终目标能否完全达到设计要求的重要环节,同时系统测试环节也是系统开发过程中的"软肋"。一般情况下,业界对开发人员的投入比例偏大,而不太重视测试,这也是导致很多国内软件品质不稳定的原因。我公司对测试工作非常重视,测试过程严格按照公司质量体系标准<软件测试控制程序>执行。测试方法除采用传统的测试方式外,还采用了先进的测试工具辅助测试。系统安装完成后,首先拟出一个测试方案,详细确认每个测试环节的测试用例,并与业主讨论经过后,按计划进行测试。对系统每一项测试有详细的测试记录,同时用户方、投标人代表签字确认,并附有详细的分析报告。测试目标和原则测试目标测试过程是验证建设成的最终系统是否满足原始需求而且遵循系统设计,测试的目标是尽可能多的发现系统中存在的错误,并能发现及预言潜在的错误,以保证系统正常运行。测试的最终目的则是发现应用软件的错误,达到在硬件和系统软件支撑下,应用软件系统能正常、稳定、可靠运行的目的。测试原则制定规范和完整的测试计划,严格按计划组织测试,排除测试活动的随意性。预先组织和准备好各种测试用例和测试数据,以保证测试活动的顺利开展。测试输入数据应与对应的预期输出结果配套。测试用例中不但有合理的输入条件,还要有不合理的输入条件。妥善保存各种测试文档及测试用例与数据,为以后软件重测和维护提供方便。对每一个测试结果要做全面的分析和检查。系统测试过程中发现的所有缺陷用统一的缺陷管理工具来管理,开发人员根据缺陷管理报告及时改正错误。测试组织针对本项目实施特点,我公司成立专门的测试组织来完成测试工作,测试的组织结构是属于项目组,可是独立于开发组,测试经理的直接汇报渠道是项目经理。其角色和职责分别定义如下:测试组织角色和职责定义角色职责备注项目经理全面领导,对测试项目进行监督、管理,对重大问题进行决策。测试经理测试中的主要角色,测试中所有环节的组织者,和主要实施者;负责制定<测试策略>和<测试计划>;负责单元测试、集成测试、系统测试活动的组织安排;确保所有测试活动按照计划进行,确保测试记录得到维护,并根据测试工具的有效应用产生测试度量数据;负责<测试分析报告>。需求经理负责测试用例的分析和设计;负责开发业务方面的测试用例。测试工程师在测试经理的组织下,负责测试的设计、测试用例的开发和测试执行工作。架构师负责性能测试用例的开发和执行;负责性能测试指标的定义和结果分析;协助开发组定位性能瓶颈和确定优化应用系统。质量管理人员协助测试经理完成测试过程中的质量管理;测试内容本项目的测试种类包括:单元测试、集成测试、功能测试、界面测试、健壮测试、安全测试、性能测试、安装测试、文档测试等。在进行测试前,需要编写详实的测试方案,其中包括测试时间安排、测试准则、测试用例、测试范围、测试目标、测试人员、出错处理流程及处理结果等内容。在测试案例中应包含对异常情况处理的测试,如数据不全、数据类别有误、数据不合法等。