分类： 银行职业资料

集中式代理业务平台二次开发和投产流程.doc
集中式代理业务平台二次开发指引.doc
集中式代理业务平台整体介绍.ppt
集中式代理业务平台－参数设置（新增业务）手册.doc
集中式代理业务平台－开发编码规范.DOC
集中式代理业务平台－数据库设计(V1.1).DOC
集中式代理业务平台－数据库设计(V1.2).DOC
集中式代理业务平台－数据库设计(V1.4).DOC
集中式代理业务平台－数据库设计(V1.61).DOC
集中式代理业务平台－数据库设计(V1.62).DOC
集中式代理业务平台－数据库设计(V2.0).DOC
集中式代理业务平台－新终端、联机、批量二次开发范例.doc
集中式代理业务平台－第三方BICE配置范例(联通业务).doc
集中式代理业务平台－设计说明书(V1.3).doc
集中式代理业务平台－设计说明书（V1.1）.doc
集中式代理业务平台－设计说明书（V1.2）.doc
义务社保通讯接口.doc
定期一本通代发业务配置及二次开发说明.doc
集中式代理业务平台应用开发规范.DOC
集中式代理业务平台版本说明表.xls

业务操作手册：
业务操作手册集中式代理业务平台系统后台管理端联通缴费、数字电视代扣操作说明.doc
业务操作手册集中式代理业务系统前台操作手册.doc

开发和投产流程：
开发和投产流程XXXX分行XXXX代理业务二次开发登记表(模板).doc
开发和投产流程XXXX分行XXXX代理业务外联接口登记表(模版).doc
开发和投产流程XXXX分行XXXX代理业务需求(模版).doc

批量管理：
批量管理集中式代理业务平台平台参数设置说明书.doc
批量管理集中式代理业务平台二次开发文档(批量平台).doc

新终端：
新终端集中式代理业务平台新终端前台变换配置详细说明.ppt

第三方通讯：
第三方通讯集中式代理业务平台BICE通信前置总体说明.doc
第三方通讯分行通讯前置安装维护手册.doc
第三方通讯分行通讯前置用户操作手册.doc

联机交易：
联机交易集中式代理业务平台二次开发文档（联机平台）.doc
联机交易集中式代理业务平台通用打印模板配置方法.doc
联机交易中间业务平台用户参考手册.doc
联机交易中间业务平台用户开发手册.doc

集中式代理业务平台整体介绍.ppt

代理业务系统集中是顺应业务自身发展的需求和银行内部集约化管理的要求而提出的。

总行对中间业务技术平台规范（maps平台）的推广要求也非常明确。

主要任务是完成“数据集中、平台迁移”。

在二次开发管理上要继续兼顾二级分行的自由度，允许其在框架内实现本地特色。

根据代收代付、代发代扣类代理业务发展的情况，对现有系统的功能做一些整合、扩充和改进。

框架
MAPS实质上是一个基于交易方式的业务系统开发平台，它搭建了一个前台、后台、主机、第三方之间的一个框架，提供了一些配置手段，允许对通讯报文、交易处理流程等进行配置。

流程
交易处理流程通过对不同组件的搭配和控制来实现。

组件
系统自带通讯包处理组件、对主机访问的组件、第三方通讯的组件等，除此之外，允许自行开发组件以实现不同的业务逻辑。

对外发件讲解-对外发件规范培训.ppt
对外发件讲解-外发邮件的流程及编写要点.ppt

对外发件讲解-外发邮件的流程及编写要点.ppt

总体方案、POD
业务需求分析说明书及确认函
非功能性需求说明书及确认函
功能评审会议通知、项目范围评审会议通知
总体方案延期申请
需求变更
请示报告、部门沟通等其他发件
风险提示函

发件人和收件人要求
发送材料要求:《POD》、《总体方案》、《项目范围和计划表》、《项目计划安排》。
回复时间要求
备注要求
新增应用要求
总体方案要求

总体方案延期申请的编写要点
如果项目的交付时间是有明确规定的且不能延迟的，延期申请应慎重审批同意，因总体方案延期势必导致后面开发工期的压缩。
对于由于中心外部原因导致的延期，项目组是否在上报延期申请前尽力消除风险，是否提前上报风险提示函或请示报告。

应用产品后评估管理.ppt
应用产品后评估管理-应用产品后评估手册及指引培训.ppt
应用产品技术规范及业务风险后评估管理规范及操作指引培训.ppt

培训内容简介：
介绍应用产品后评估管理工作手册中的修订点，对应用产品后评估指引进行介绍，并对后评估中常见问题进行分析。

应用产品技术规范及业务风险后评估管理规范及操作指引培训.ppt

培训内容：
一、相关术语定义介绍
二、应用产品后评估管理流程
主要介绍项目各个阶段的后评估管理流程，及相关注意事项
三、风险后评估问题的考核
主要介绍后评估问题的考核指标
四、Rational后评估问题操作流程
主要介绍在rational上如何提交后评估问题
五、主要参考文档

应用产品后评估包括技术规范后评估和业务风险后评估
业务风险后评估：是指对应用产品是否存在业务操作、流程等方面的漏洞，从而引起资金、账务、信息安全等风险进行后评估。
技术规范后评估：是指对应用产品是否遵循中国工商银行研发相关技术规范（包括主机、平台、网络、安全、信息等）进行后评估。

注释：依据《应用产品后评估管理工作手册》，开发中心在开发过程中发现的不符合技术规范问题，作为项目测试问题统一管理，不作为后评估问题处理

应用产品后评估管理流程

第三条总体方案设计阶段：
在总体方案设计阶段，应用架构师需再次对业务需求进行风险评估，并在总体方案中说明目前业务需求或方案设计中可能存在的业务风险，建议的解决或规避方案，并与业务部门进行充分沟通，同时在Rational中登记业务风险后评估问题，并需在业务部门反馈意见后更新相关问题的状态。

第四条功能设计阶段：
功能设计阶段编写业务需求分析说明书时，开发经理（开发组长）需组织开发人员对业务需求中可能存在的业务风险进行评估，并在业务需求分析说明书中说明存在的业务风险，建议的解决或规避方案。同时在Rational中登记业务风险后评估问题，由应用架构师负责与业务部门进行沟通，对确认需要解决的问题，由开发经理落实并登记版本计划，如开发经理对确认结果（包括是否属于业务风险和解决措施）有异议，需提交架构办各基地负责人进行仲裁。

第六条系统测试阶段
在系统测试阶段，测试经理（测试组长）需组织测试人员，对业务需求和功能设计中可能存在的业务风险进行评估，提出建议的解决措施或规避方案，同时在Rational登记业务风险后评估问题，由应用架构师负责与业务部门进行沟通，对确认需要解决的问题，由开发经理落实并登记版本计划。如开发经理或测试经理对确认结果（包括是否属于业务风险和解决措施）有异议，需提交架构办基地负责人进行仲裁。

应用开发中的非功能性设计.ppt
应用系统的非功能性设计开发.doc

培训内容简介：

现在项目开发中，首先关注的是功能是否按需求实现，对于非功能性的考虑一般都是在第二位甚至忽略了。但到生产环境的时候，一旦出现问题，该如何分析，如何才能分析，都是非功能性的问题；应用的“能用”、“可用”、“好用”中，后两个都是非功能性的问题。本课程中，讲师将结合自身的实际开发和生产支持经验，介绍开发中应考虑的非功能性因素的影响和解决方案。

应用系统的非功能性设计开发

一、我们应用的特点
业务创新
用户量大
数据量大
分布范围广
7X24小时运行
时效性要求高

二、存在这样的情况
上午解决生产问题
下午解决适应性、系统测试问题
晚上开发
1、这是一个恶性循环
上个(N个)版本的问题要解决
当前版本要投产
后续版本要开发

2、改变这种状态，争取能够逐渐
快速解决问题
高效率工作
高质量工作
争取问题越来越少

三、业务功能要实现
比较容易：按软需完成

四、业务流程要完整
有些困难：要懂基本的业务流程

五、不能一用就出错
有些挑战：要做基本的测试

六、不能一出错就退出
有点严格：基本流程要闭环

七、简单看测试通过的能用，不一定行！
测试不能覆盖全部代码
测试不能模拟完全生产的数据情况
•尤其是技术类型的系统、项目
测试不能模拟完全用户使用情况
测试不能模拟完全生产的环境情况

九、主动控制超时
物理网络的不确定性
其他系统的不确定性

十、系统能及时响应
超时处理也是一种响应

十二、记日志
系统日志
•系统启动、停止……
应用日志
•交易正常、异常……
业务日志
•柜员在何时使用了哪个交易……

十三、日志分级别
严重异常错误
一般异常错误
警告信息
一般信息

十四、分别记哪些信息
错误的堆栈信息
错误发生时的数据信息

银行软件研发中心培训资料：应用系统数据模型设计技术规范培训.ppt

完成本课程后，应该掌握以下内容：
了解ER数据模型
了解范式化设计
掌握数据模型管理
掌握数据设计
掌握逻辑数据模型设计
掌握物理数据模型设计

第一范式：一个关系R的所有属性都是原子的，即属性不可分。
第二范式：对遵循第一范式关系模式R，且它的所有非键属性要完全函数依赖于主键中的每个组成键，则称关系模式R属于第二范式。
第三范式：对遵循第二范式关系模式R，而且它的非键属性全部直接依赖于主键，而不依赖于其它非键属性。则称关系模式R属于第三范式。

数据模型管理(二)
逻辑数据模型采用ERWIN工具进行E-R图绘制建模。企业级逻辑数据模型、应用级逻辑数据模型应包含逻辑数据模型ER图和逻辑数据模型说明文档两部分内容。
ER图应包含以下内容：主题域视图(StoredDisplays）、实体、关系：
a.主题域视图应至少包含：主题域视图的名称、定义。主题域视图的定义用业务语言描述主题域视图所表达的主要内容。
b.实体应至少包含：实体名称、实体定义、以及实体主键、普通属性。
c.实体间关系分为标识性关系、非标识性关系、多对多的关系，需选择其中一种作为两个实体之间的关系。
逻辑数据模型说明文档应包含以下内容：
a.文档说明、术语定义、本次版本与上次版本的变更历史与变更内容描述。
b.数据模型内容说明、实体清单，可适当补充场景分析。

数据库总体设计
对数据库进行选型，并在项目总体方案中明确。
根据上述分析，形成简要的ER图（仅含主键、外键等重要属性），完成项目总体方案中关于数据结构的概要设计。
将业务数据量和数据量变化趋势分析、需要保留的业务数据（或帐务）和处理原则、业务数据的可变性分析体现在业务需求分析说明书的中。
从数据质量管理角度，充分了解系统功能对数据信息在各个数据质量维度的业务规则要求。

逻辑数据模型设计步骤
确定应用所属数据区
抽取数据项
明确实体
分析实体间的关系
对实体分类
确定各应用逻辑数据模型所有实体在本应用是主数据源，还是辅数据源
绘制E-R图

物理数据模型设计要求(一)

物理实现方法
操作执行频度
操作类型、操作执行条件
容量、增长量估算
条件判断的字段或字段组合，以及字段的区分度
是否有定期数据加载或清理

基本设计要求
物理数据模型设计阶段需明确数据各维度的业务规则和技术规则，将质量管理实现方式为DDL的相关限制明确到到DDL中实现。
物理数据模型设计阶段需按照《数据生命周期管理技术规范》明确各表结构在线阶段、归档阶段保存时间。
表结构需设计登记维护信息（比如创建人、创建日期、创建时间，最后更新人、最后更新日期、最后更新时间）。
主键、外键的建立是以逻辑数据模型E-R图为依据。
表结构字段设计应遵循技术元数据标准。

软件需求说明书模版（用例）.doc
软件需求说明书编写手册（用例）.doc

软件需求说明书模版（用例）

目录
第1章 总体说明 1
1.1 项目背景 1
1.2 需求概述 1
1.3 组织机构和角色 1
1.4 词汇表 1
1.5 数据流图 1
1.6 与其它应用、系统的关系 2
1.7 假定和约束 2
第2章 功能需求描述（用例部分） 2
2.1 用例列表 2
2.2 系统用例图 2
2.3 XXX用例如：主动积存用例 3
2.3.1 用例描述 3
2.3.2 用例图（可选） 6
2.3.3 输入输出信息定义 7
2.3.4 界面原型 8
2.3.5 业务场景分析 8
第3章 功能需求描述（非用例部分） 9
3.1 功能列表 9
3.2 XXXX应用 10
3.2.1 XXXX交易 10
第4章 非功能需求描述 11
4.1 系统方面的限制性要求 11
4.1.1 系统安全要求 11
4.1.2 系统审计要求 12
4.1.3 数据移行要求 12
4.1.4 系统灵活性要求 12
4.1.5 可用性要求 12
4.1.6 可靠性要求 12
4.1.7 性能要求 12
4.1.8 系统服务时间要求 12
4.2 业务应急处理要求 12
4.3 投产要求 12
4.4 其它要求 13
第5章 参数管理应用 13
5.1 参数管理应用 13
5.1.1 参数维护 13
5.1.2 查询 13
5.1.3 本地查询 13
5.1.4 文本检查 13
5.1.5 客户端下载 13
5.2 业务涉及的所有参数表功能描述 13
5.2.1 功能说明 13
5.2.2 字段说明 14
5.2.3 管理维护要求 14
5.2.4 表样 14
5.3 参数表维护顺序关系 14
5.4 控制关系 14
5.5 参数维护职责 14
5.6 注意事项 15
第6章 业务实体分析 15
6.1 业务实体总体说明 15
6.2 XXXX实体 15
第7章 业务数据情况 16
7.1 业务数据量和数据量变化趋势分析 16
7.2 需要保留的业务数据（或账务）和处理原则 16
7.3 业务数据的可变性分析 17
第8章 通用规则与约定 17
第9章 附件 17

软件需求说明书编写手册（用例）

目录
第1章前言 1
第2章用例介绍 1
1.1. 用例的定义 1
1.2. 用例模型的主要内容 2
1.2.1. 用例模型的组成要素 2
1.2.2. 用例模型的描述方法 3
1.3. 用例的特征 4
1.4. 采用用例建模的优点 4
1.5. 用例的适用范围 5
第3章关于参与者的发现 5
第4章用例模型的编写方法 7
4.1用例规约 7
4.2用例图 10
4.3编写用例的一般步骤 11
第5章用例模型的调整 12
5.1参与者之间的关系 12
5.2用例之间的关系 13
5.2.1包含 13
5.2.2扩展 14
5.2.3继承 15
5.3调整用例模型 15
第6章关于用例的粒度划分 16
第7章用例模型的检查方法 17
第8章关于用例的协作编写 18
第9章编写用例的注意事项 18
第10章其他部分的编写方法 19

1-module_00_introduction.pdf
2-module_01_what_is_use_cases.pdf
3-module_02_fundamentals_of_use_case_modeling.pdf
4-module_03_establishing_the_vision.pdf
5-module_04_finding_actors_and_use_cases.pdf
6-module_05_getting_started_with_use_case_modeling_workshop_cn.pdf
7-module_06_writing_use_case_descriptions.pdf
8-module_07_adding_formality.pdf
9-module_08_reviewing_use_cases.pdf
10-module_09_complementing_use_case_descriptions.pdf
11-module_10_driving_the_development_practices_cn.pdf
12-Module_11_requirements_analysis.pdf
13-module_12_use_cases_across_the_lifecycle_and_wrap_up.pdf

中间业务平台C语言编码培训.ppt
中间业务平台C-Pro*c语言编码培训.ppt

中间业务平台C语言编码培训

在完成本课程后，您应该了解如下内容：
一、变量的声明和初始化
二、字符串处理及相关异常
三、数据类型转换
四、在上述的情况下如何避免溢出
五、函数和公共库的使用原则
六、需要遵循哪些基本的编码规范
七、UNIX下系统调用简介（初步介绍）
八、进程管理、进程间通信简介（初步介绍）
九、附录：主要介绍了UNIX下如何进行编译

前提条件
1. XLC编译器 C89标准
2. 32位方式编译
3. AIX 小型机 
4. 只涉及中间业务平台常用编码
5. 了解C语言基本编码

基本变量类型及其最大长度
Char a[] char *a char a[10] CHAR
INT（9） LONG（9） SHORT（4）
*LONG LONG (18)
DOUBLE（15） FLOAT(7)

溢出问题是C语言编码最常见的问题
一般不使用小数，精确到分

中间业务平台Pro*c语言编码培训

Pro*C总体介绍
Pro*C 程序编写的基本框架。
变量定义
静态、动态sql语句与绑定变量
游标的使用
错误处理
封装SQL语句

批量相关内容介绍.doc
批量相关内容介绍(2).doc
批量相关内容培训介绍.ppt
批量相关内容培训介绍(2).ppt
批量调度程序管理流程及规范.doc
日间批量目录.doc
外部会计系统主机接口规范.doc
对外供数指导手册.doc
批量操作常见问题分析及解决.doc

批量相关内容介绍.doc

一、名词介绍
联机业务：称为实时处理业务，在营业时间运行，对特定的少量数据操作。
批量业务：是预先写好的一些作业流，一般在非营业时间运行，对大量数据的集中处理。
地区：mag_area.area_code
时区：mag_area.zone_code
时区组：mag_area.zone_group，将同一个批次的地区逻辑上组合在一起，跑批量时的概念，和主机的批次对应。
时区组对应的工作日期：selectworkdatefrommissign.mag_workdatewherevalid=’1’andgroup_code=&3;
cmisdate：workdate||to_char(sysdate+t_diff/24,’HH24MISS’)
1、workdate：时区组日期，默认为时区组1的日期；
2、sysdate：机器日期；
3、t_diff：地区对应时区和北京时区的差值。
二、日间批量
日间批量，主要是对上游提供给CM2002系统的数据进行处理。
1、日间批量处理流程
日间批量，一般分为两步：数据导入和批量处理。
数据导入是将接收到的上游数据通过SqlLoader的方式并发导入CM2002系统的临时表。主要步骤如下：
1、获取相应的zip文件；
2、清空临时表数据；
3、解压zip文件；
4、对每个数据文本（过滤空文本）生成控制文件、批量处理文件；
5、多进程并发进行sqlloader；
6、取得待处理地区列表（cmis3.mag_batch）。
批量处理主要是对临时表中数据进行转换，以及调用接口对临时表中的数据进行业务处理。
2、日间批量所需内容
1、文件结构（GFT提供的为准，系统设计阶段提供）
2、临时表表结构
3、日间批量接口程序
3、日间批量类型及相关目录
主要包括如下日间批量：
1、信贷日间批量（国内）
2、信贷日间批量（海外）
3、贸易融资日间批量
4、非信贷日间批量
5、CCRM日间批量
6、SADL日间批量
7、EAP日间批量
8、IRA日间批量
9、人行征信日间批量

批量相关内容培训介绍.ppt

5、作业并发参数初始化
作业并发参数初始化即作业参数加载，有两种方式：静态加载和动态加载。通过设置work_batch_time下的work_init_type参数来识别。0代表静态加载，1代表动态加载。
6、作业分组原则
将作业按照应用或者功能分为不同的组，主要的目的就是看作业是属于哪一个分组，因为在作业调度时同一个分组的作业目前不允许并行运行。而且可以在组上设置优先级，保证优先级高的分组先运行。
组的识别是通过work_batch_time中的work_application来进行识别的。对应的字典表都在da_work_appInfo中。
7、并行调度原则
情形1：当前没有作业在运行：根据组的执行优先级，查找本进程能运行的第一个作业进行运行。
情形2：当前已经有一个作业在运行了，则可能有以下几种情况：
如果当前作业能并发，且还有相应的参数没有执行，则运行该作业的没有运行的参数中的一个；
如果当前作业能并发，且已经没有相应的参数能执行了；或者是当前作业不能并发，则查看下一个专业是否有作业能运行，能则运行，不能则继续查找别的专业的作业，直到查询完所有作业或者是能找到一个作业运行为止。
情形3：当前有多个作业在运行，则首先查找按组优先级高的正在运行的作业是否还有参数能运行，如果有，则运行下一个该作业的参数；如果没有，则查找正在运行的下一个分组的作业是否有参数能运行，有则运行，没有则继续查找；如果查找完所有正在运行的分组作业都没有作业参数能运行，则首先查看目前没有运行的分组是否有作业能运行，有则运行，没有则等待；

架构设计与架构师讲义.ppt

IT系统的架构是包含软件组件、硬件组件，组件的外部可见特性和组件之间关系的系统结构
从架构设计师的角度来看
架构就是一套构建系统的准则
通过这套准则，把一个复杂的系统划分为一套更简单的子系统的集合
这些子系统之间应该保持相互独立，并与整个系统保持一致

企业架构
从企业的整体业务和战略出发，从技术上制定用以支持企业业务和战略的各种应用、数据和基础设施，企业架构还对全企业的信息化系统的管理、维护和发展制定体系结构
IT架构必须符合企业架构的战略规划
架构设计师在构建软件系统时
要考虑这个系统的技术架构以及其应满足的功能性需求
要关注整个架构的非功能性需求的各个方面
一个好的架构设计师甚至还需要考虑所构建的系统架构是否合乎美学要求
一个好的架构设计并不能只从功能角度出发，还要考虑很多其他的因素
需求阶段，负责理解和管理功能需求和非功能性系统需求，提出解决方案
在需求越来越明确后，关注点开始转移到组织开发团队成员和开发过程定义上
软件设计阶段，负责对整个软件体系结构、关键构件、接口和开发政策的设计
编码阶段，成为详细设计人员和开发人员的顾问
随着软件开始测试、集成和交付，集成和测试支持将成为架构师的工作重点
软件维护，开始为下一版本的产品是否应该增加新的功能模块进行决策

IT架构师应有的特点
技术主管：是项目的技术总管，要有很好的领导才能
理解软件开发过程：指导开发小组做什么、以及怎么做
拥有技术知识：宽阔的知识面，但不一定是某单一领域的专家
拥有设计技巧，为关键性设计决策，包括主要结构、技术和业务组件拥有很好的程序设计技巧，了解不同语言的设计模型特点大多数成功的架构师，可以在一些项目中充当核心程序员
有业务领域的知识：需要拥有相关业务领域的知识
要具有很好的沟通能力

架构师角色的划分
应用架构师（ApplicationArchitect）
数据架构师（DataArchitect）
基础结构架构师（InfrastructureArchitect）
网络架构师（NetworkArchitect）
性能架构师（PerformanceArchitect）
安全架构师（SecurityArchitect）
系统管理架构师（SystemsManagementArchitect）
技术解决方案架构师（TechnicalSolutionArchitect）
测试架构师（TestArchitect）
客户架构师（ClientArchitect）
软件架构师（SoftwareArchitect）
系统架构师（SystemsArchitect）

三、架构设计的标准规范
IBM采用GSMethod方法论指导架构的设计，并使用UML进行模型设计
IBM在架构设计上非常强调模式（pattern）的重用
模式是由三部分组成的规则，它表示了一个特定环境、一个问题和一个解决方案之间的关系
每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心
模式的主要类型有参考架构、结构模式、设计模式、分析模式
使用模式的目的在于充分利用已有的软件开发经验、降低风险、提高质量、提高效率
参考架构是一个预先确定的架构模式、或者模式的集合；可能部分地或者完全地用具体例证说明、设计、并证明在特殊的业务和技术环境下可用，以及支持先前的成果；通常，这些成果是对以前项目的经验总结