【毕业学位论文】(Word原稿)信托公司业务综合管理系统的设计与实现-软件工程

中图分类号： 学校代码： 10055 密级： 硕 士 专 业 学 位 论 文 信托公司业务综合管理系统的设计与实现 文作者 指导教师 教授 申请学位 工程硕士 培养单位 软件学院 学科专业 软件工程 研究方向 项目管理 答辩委员会主席 评 阅 人 南开大学研究生院 二一 三 年 十 月 摘 要 I 摘 要 随着我国金融产业快速稳健的发展，我国信托行业正在进入健康高速的发展时期，信托公司的发展已成功迈上了新的台阶。信托业务的不断创新、营销手段的多元化、风险的有效管控、客户服务水平的提高以及财务体系的特殊性和复杂性等多方面因素，要求信托公司必须构建高效统一的管理运营、风险 控制 而优化并整合业务流程，实现流程化处理业务，提高客户的理财服务质量，提高资产运用效率和保障，实现全公司的业务信息共享，为信托公司领导提供全面的决策信息，建立信托公司的核心竞争力。 信托业务综合管理系统是信托公司信息化建设的核心，对信托业务中涉及的信托项目、委托人、受益人、信托合同、用款人、运用合同进行全面管理，并将各类信息进行有机整合 ，用工作流将业务向前推进 ， 其他信息系统，如财务、风控等都需要围绕在信托业务综合管理系统周围，以业务系统数据为基础，才不致成为信息孤岛，才能体现出价值。 本文结合信 托业务操作特点及信托公司需求阐述了信托业务管理系统的设计和实现 过程 。文章首先论述了信托公司信托业务管理系统建设的现状，本文研究的意义、目标和内容，然后结合信托业务和信托业务参与角色对用户需求进行了分析 ，接着对系统的技术架构、功能模块、数据库等进行设计，之后 文章对部分 系统功能的实现细节 进行了阐述 。 关键字 ： 信托公司 信息系统 设计 I s s is of on a of of of of to as as T so as to of is of It to in of as to on of of on of of as as of II of of of a on of 录 录 第 1 章 绪论 . 1 托业务综合管理系统信息化建设研究背景 . 信托行业现状 . 信托业务系统信息化建设现状 . 信托业务系统信息化建设的意义 .托 公司及其业务概述 . 信托关系及信托角色 . 信托公司典型业务 .文的研究目标、内容及组织结 构 . 本文研究目标 . 本文的内容及组织结构 . 2 章 系统分析 . 6 行性分析 . 应用上的可行性 . 技术上的可行性 . 经济上的可行性 .求分析 . 系统使用人员分析 . 功能性需求分析 . 非功能性需求分析 . 3 章 系统设计 . 12 统架构设 计 .统功能模板及菜单 .务流程设计 .据库设计 . . 表结构 .作界面设计 . 4 章 系统实现和测试 . 24 统运行环境 .统技术框架 . 录 V 分系统功能实现 . 系统登录和密码策略 . 增删改查的实现 . 信托 项目立项功能的实现 . 信托项目营销功能的实现 . 信托项目运作功能的实现 . 表 增的实现 . 系统日志的实现 . 定时任务的实现 . 审批流的实现 .0 页面导出功能实现 .统测试 . 功能测试 . 性能测试 . 5 章 总结与展望 . 51 要工作 .望 .考文献 . 53 个人简历 在学期间发表的学术论文与研究成果 . 55 第 1章 绪论 1 第 1 章 绪论 托业务综合管理系统 信息化 建设研究 背景 随着金融市场 的开放和监管政策的放松，不同类型的金融子行业和金融机构之间业务往来日益增多，融合度不断加强 1， 信托与银行、保险、证券，构成一个国家或地区金融体系中的四大支柱，是金融体系中不可或缺的重要组成部分。 托行业现状 信托业在国内的发展可谓一波三折，从 1979年第一家信托公司成立到现在的 30多年间，经历了几次由兴到衰，再由衰到兴的起伏，六次清理整顿，信托公司数量从高峰时期的 1000多家，缩减到目前的 60多家，这在其他金融业态历史上都是不曾有过的。随着信托行业“一法三规”的陆续颁布与实施，信托公司业务 发展逐渐走上正轨，业务规模逐年递增，截止 2012年年底，全国信托公司所管理的信托资产规模达 过保险业 为仅次于银行的第二大金融业态。 托业务系统信息化建设现状 与银行、保险等行业相比，信托公司的信息化水平普遍相对较低，多数公司还处在依靠 公软件进行半手工处理的阶段，信托业务系统建设没有跟上信托业务发展的脚步。造成这种情况的原因是多方面的， 归纳起来主要有以下三点，第一，信托规模的大幅度提升是近两三年的事情，规模没上来时，体现不出信息化的重要性；第二 ，信托作为金融体现中的试金石，业务形式多变，创新不断，这给信托业务信息化带来一定难度；第三， 信息业务系统软件供应商稀少 ， 他们 认为信托 不像 银行、保险等其他金融业态， 数量众多，市场较大，且更重视和依赖信息系统，信托公司没有足够的油水激发供应商的信托业务信息化系统开发热情。 第 1章 绪论 2 托业务系统信息化建设的意义 随着信托业务的不断发展壮大，信托业务人员发现， 日常的项目台账、项目文档越来越繁多和杂乱，项目状态的跟踪和项目信息的检索变得越来越困难，项目资金数据的计算工作量巨大，出错几率明显增多， 这些麻烦让他们疲于 应付，制约着信托公司进一步扩大信托业务规模， 他们迫切希望有一个工具能帮他们有条不紊的管理项目各项数据，自动计算资金数据，减少重复性劳动，以及在希望查看 信托项目相关信息 时 能 快速检索出来，这个工具就是信托公司业务综合管理系统 。 开发 这么 一款符合信托业务特点的业务综合管理信息化系统对辅佐信托行业继续高速发展将发挥巨大作用，有着重要意义。 信息系统让企业业务步入一个新的台阶 6。 托公司 及其 业务概述 托关系及信托角色 信托是指委托人基于对受托人的信任 , 将其所有的财产权利转移给受托人 , 由受托 人根据信托法的规定 , 按照委托人在信托文件中的意愿 , 并为了受益人的利益 , 对信托财产进行管理和处分而形成的法律关 系 5。 信托关系描述：委托人将其财产托付给受托人，受托人按照委托人的意愿将信托财产进行运用和管理，所得收益归委托人指定的受益人所有，受托人收取一定的信托报酬 2。 可以看到一个信托计划中涉及三个角色：委托人、受托人、受益人 。 受托人即信托公司 ，委托人是投资人，受益人可以是委托人自己，也可以是委托人指定的其他人 。 第 1章 绪论 3 托公司典 型业务 信托公司 典型的业务 如下图所示 ， 投资者将自己的资金委托给信托公司 ，信托公司将信托资金存入专用的银行专户保管，信托成立后 ，信托公司将资金贷款给上市公司 A， 公司的贷款提供担保，同时 托公司将投资收益分配给投资者。 图 托公司职能 图 托关系 示意图 第 1章 绪论 4 文的研究目标 、内容及组织结构 文研究目标 本文 研究目标是设计并实现一个符合信托业务特点的综合管理平台系统，使其成为信托公司的业务信息平 台，为信托公司发展助力。 系统要达到的具体目标如下： 1. 为信托公司提供一个业务审批平台，信托公司内部的审批操作，如项目立项审批、收付款审批等，都可在系统中完成 ，同时也可将工作流程在系统中串接，由流程来推动任务启动、进行、直至完成。 2. 为信托经理们提供一个日常工作平台 ， 帮助 他们有条理的管理信托项目数据，随时记录项目过程数据，方便的调阅项目历史数据，项目的利息、收益、费用由系统帮助自动计算，同时系统可友好的提前提醒信托经理项目操作时点，如收息、分配等。 3. 为公司领导提供一个监控和决策平台， 公司领导可以 在系统中查询公司的信托项目信息，监视各项目运行状态，决定是否需要干预。同时系统可将项目数据按各种口径进行统计、整合，出具各类报表，这些报表数据可作为公司领导决策的依据。 4. 为系统管理员提供一个集中的系统维护平台，系统管理员可方便的维护公司员工，并给他们分配系统操作权限，同时可通过日志，监控系统用户的系统操作行为。 文的内容及组织结构 本文共分为五章，各章内容如下： 第一章绪论，主要描述了信托行业 现状，信托公司信息化建设现状及建设信息化系统对于信托公司的意义，简述了信托关系的形成和信托公司的 典型业务，最后本章描述了本文的研究目标和本文的主要内容和组织结构。 第 1章 绪论 5 第二章系统分析，主要对系统的可行性和 系统需求进行了分析，可行性分析从应用、技术和经济三方面进行，需求分析分成功能性需求和非功能性需求两方面进行描述。 第三章系统设计，主要描述了系统的总体架构设计、系统功能模块的划分、数据库设计及操作界面设计等内容。 第四章系统实现和测试，本章主要对系统主要功能点的实现细节进行描述，同时介绍了系统测试 和部署等 相关工作 。 第五章总结和展望，本章分总结和展望两部分，总结部分对设计和实现本系统的主要工作和成果进行总 结，展望部分总结了系统的不足和需要改进的方面，并提出了系统拟进一步研究的内容和工作。 第 2章 系统分析 6 第 2 章 系统分析 行性分析 用上的可行性 随着信息技术的发展，各行业、各公司都开始自己的信息化建设，信息化程度已成为一个公司核心竞争力和企业形象的体现 7。信托作为第二大金融业态，在信息化方面已相对落后，同时信托业务的快速发展也使得信托从业者对自己管理的信托信息资产力不从心，迫切需要一个系统帮助他们。因此，可以说信托业务综合管理系统的出现是大势所趋，人心所向。 术上的可行性 近年来 ，信息技术发展迅速，新技术层出不穷，可谓日新月异。 出于灵活性和可扩展性考虑，目前 企业信息化 系统多趋向 使用 B/ 开发 B/要有 术平台 ， 这两个平台功能都很强大，配合 前端展现技术，可实现丰富的功能，也能实现各种所需的特效 。许多优秀系统的出现 ，如大互联网公司 度等，大电商淘宝、京东等 ，也给我们提供了参考，指引了信息化技术的方向。 种类繁多的开发框架、快速开发模型也不断涌现，并且很多都是开源的，如 用这些框架可大大简化 系统开发的难度和周期。 很多使用框架的成功案例，并且相关技术文档丰富而完整，并且容易获取。 服务器 性能正按照摩尔定律飞速增长着， 虚拟技术、集群技术、存储技术逐渐成熟，网络带宽逐渐增大，这些为信息化系统的高速、稳定运行提供了硬件保障。 综上所述，信托业务综合管理系统在技术上是可行的。 第 2章 系统分析 7 济上的可行性 如前所述，当信托公司业务发展到一定规模，信托项目相关数据若只能手工或半手工处理，信托从业人员将会力不从心，疲于应付 ，这种状况将对信托业务进一步增长造成阻碍，成为瓶颈。因此，信托综合业务管理系统将保障信托业务持续稳定的增长，为信托公司带来更多收益 。 求分析 统使用人员分析 本系统可能的使用人员有如下几类：信托经理、系统管理员、公司领导。不同类型人员有着 不同的需求，下面将分别进行分析。 能性 需求分析 1. 信托经理 提交审批 ：信托项目从立项、运作到结束的整个生命周期中，每个环节都需要审批，信托经理需要按照公司既定的流程，提交相关的要素信息和文档，提交领导 审批。 项目管理 ：信托项目的生命 周期分为立项、营销、成立、生效、运行、清算等多个阶段，不同的项目阶段有不同的任务，信托经理需要管理这些阶段，并完成每个阶段要做的事情。 委托人管理 ：包括委托人本身的管理和委托人资产的管理， 信托经理要维护 委托人 相关 信息， 信息发行时对委托人进行 营销 、预约、签合同、收信托款，项目运行过程中，信托经理要对委托人进行 收益分配 、信息披露、本金返还 等 业务 。 用款人管理 ：包括用款人本身的管理和用款人资产管理， 信托经理要维护用款人相关信息，与用款人签订融资合同，信托生效时，给用款人放款，然后根据合同约定对用款人进行收息收回本 金操作。 第 2章 系统分析 8 信息查询 ： 信托经理经常需要解答投资人和用款人对于信托项目的疑问，因此需要能很方便的查阅项目相关信息，同时信托经理也有需要对自己管理的项目进行统计分析，项目做了多少规模了，收益情况怎么样，这个客户来买过多少此信托产品，规模多少等等。因此，信托经理有随时统计查询项目信息的需求。 2. 公司领导 审批： 公司领导需要对信托经理提交的各类申请进行审批，审批时他要了解到详细的信息，以便分析和判断。 信息查询 ：公司领导的信息查询和信托经理不一样，站的角度 和高度不同，信托经理查询的是他们自己管理的项目，公司领导想要看的是公司的整体项目运行情况，总体规模多少，同比、环比增减情况，收益率、信托报酬平均值，净资本占用情况等。 图 托经理需求 第 2章 系统分析 9 3系统管理员 有了系统，就要有系统管理员，他们维护和管理系统，保障系统安全稳定的运行，他们的需求主要有如下几点： 系统用户 管理 ： 公司来了新人， 系统中就要添加用户，公司有人离职，系统中就要注销用户，用户密码遗忘了，需要系统管理员对密码进行重置，用户换了部门，系统管理员就需要对用户信息进 行修改。 用户 操作权限管理 ：公司员工各司其职，在系统也一样，各自分别操作一部分功能，需要对用户进行功能权限的分配，假如员工转岗了，他的权限就需要管理员进行调整。 日志管理与监控 ：项目 在系统中 出现了误操作，谁该负责，系统管理员可以通过系统操作日志进行分析判断，找出责任人；用户账号被人冒用了怎么办，系统管理员需要能够对冒用账号进行禁用，并且追踪用户 系统登录日志能帮上忙。 图 司领导需求 第 2章 系统分析 10 功能性需求分析 1. 同时在线人数和并发数 经过调研，目前大部 分信托公司员工 人数 在 120人 左右 ， 可能使用到系统的员工人数 大概是公司员工 总人数 的 50%， 比较频繁使用系统的大概占 1/4， 考虑到信托公司未来的进一步发展，系统设计支持 100用户同时在线，支持 50并发操作可满足要求。 2. 页面响应时间 按照普通人对 时间 延迟的 忍受程度， 普通 页面 的打开时间应在 3秒以下，较大数据查询页面的打开时间应在 10秒以下。 3. 数据保密性和 数据隔离 信息系统的开放性使信息资源的共享成为可能的同时 , 也使系统增加了遭受攻击的可能性 3。 信托公司对于信托项目的 数据保密要求是很高 的，因此， 系统 应具备完善的权限体系，保证最小权限，数据只有有权限的人才能查看和操作。 特别是客户信息和合同信息。 4. 灾备 要求 信托公司对数据的安全性是很敏感的，因此需要建立完备的数据库备份计划，保证数据库故障时能及时恢复。 图 统管理员需求 第 2章 系统分析 11 由于信托公司的业务不是实时性的，因此对于业务中断的敏感性不是太高，系统故障后恢复时间在 12小时以内即可。 第 3 章 系统设计 12 第 3 章 系统 设计 统 架构 设计 系统采用 B/用表示层、业务层、数据层 三层架构模型 ，三层间的逻辑关系如图 示 。 信息系统体系结构是信息系统各要素按照确定关系构成的系统 框架 4。 表示层 从业务层获取业务数据然后按照某种格式进行显示，或对业务层发起某种请求，如查看、新增、修改、删除等。 表示层中包含众 多的 面 ，用户在浏览器中对这些页面进行查看和操作 。 业务层 处理来自表示层的请求，如果有必要，会向数据层请求所需业务数据。处理完毕后，业务层将结果反馈给表示层。 数据层负责保存应用系统的数据，并当有请求时把它们发送给业务层。 三层架构的设计，使系统达到松耦合的目的，系统显得条理清晰，便于维护。同时三个层次各司其职，默契配合，使系统能稳定高效的运行。 图 统三层架构图 第 3 章 系统设计 13 统功能模板 及菜单 系统 根据业务需要 共划分成 七大 功能 模块，分别是 系统管理 、 客户管理 、项目管理 、 营销管理 、 资产管理 、 审批流 管理 、 报表管理 。 1. 项目管理： 管理信托项目从立项到清算整个生命周期。 2. 客户管理：管理信托项目相关的客户，包括委托人客户、受益人客户及用款人客户。 图 目管理模块菜单 图 统功能模块划分 第 3 章 系统设计 14 3. 营销管理：负责信托计划的产品销售 。 4. 资产管理：负责管理信托资产的运用。 5. 审批流管理：审批流程设计、管理和跟踪。 图 产管理模块菜单 图 销管理模块菜单 图 户管理模块菜单 第 3 章 系统设计 15 6. 报表管理：用于生成各类报表和查询 7. 系统管理：管理系统用户及其权限，系统日志，系统级参数设置等。 图 统管理模块菜单 图 表管理模块菜单 图 批流管理模块菜单 第 3 章 系统设计 16 务流程设计 项目运作流程：信托经理在 系统中维护信托项目信息，完成后可提交项目立项审批，按照公司相关规定，在线上进行审批流转，直到最后节点完成审批。项目开始进行营销， 委托人对信托产品进行认购，公司与委托人签署信托合同，并给受益人发放受益权凭证，当达到项目计划设定的成立条件后，项目进入运作阶段。把募集到的信托资金划拨给用款人，并与用款人签订运用合同，用款人按照合同的约定付息返本，同时兑付受益人收益。项目到期后，对项目进行清算、销户，项目结束。 图 务流程图 第 3 章 系统设计 17 据库设计 系统 涉及到的实体主要有：信托项目、信托专户、信托合同、受益权凭证、客户、系统用户、部门、菜单、日志、审批流。实体关系如下图所示。 图 体关系图 第 3 章 系统设计 18 结构 对实体关系进行分析，系统需要建立如下的数据表，以储存相关数据 。 信托 项目信息表 （ 列名 说明 类型（长度） 是否允许为空 目 0) 不允许为空 目名称 00) 不允许为空 目编号 00) 不允许为空 属部门 0) 不允许为空 托经理 0) 不允许为空 托规模 4,2) 不允许为空 托期限 ,2) 不允许为空 目成立日期 允许为空 托专户 0) 允许为空 目状态 0) 不允许为空 目结束日期 许为空 目描述 000) 允许为空 信托专户信息表（ 列名 说明 类型（长度） 是否允许为空 行账户 0) 不允许为空 号 00) 不允许为空 名 00) 不允许为空 户行名称 00) 不允许为空 户人 0) 不允许为空 户日期 允许为空 态 0) 不允许为空 客户信息表（ 列名 说明 类型（长度） 是否允许为空 户 0) 不允许为空 户 名称 00) 不允许为空 户 编号 00) 不允许为空 户类型 0) 不允许为空 户证件类型 0) 不允许为空 户证件号 0) 不允许为空 户性别 ) 允许为空 户生日 许为空 话号码 15) 允许为空 址 100) 允许为空 第 3 章 系统设计 19 编 6) 允许为空 注 000) 允许 为空 信托合同信息表（ 列名 说明 类型（长度） 是否允许为空 同 0) 不允许为空 同编号 00) 不允许为空 托人 客户 0) 不允许为空 同状态 0) 不 允许为空 同内容 许为空 述 00) 允许为空 受益权凭证信息表（ 列名 说明 类型（长度） 是否允许为空 益权凭证 0) 不允许为空 目 0) 不允许为空 托合同 0) 不允许为空 益权凭证编号 00) 不允许为空 益人 0) 不允许为空 益金额 4,2) 不允许为空 期收益率 2,6) 允许为空 天数 0) 允许为空 益人银行账号 00) 允许为空 益账户户名 00) 允许为空 益账户开户行 00) 允许为空 态 0) 不允许为空 运用资产账户信息表（ 列名 说明 类型（长度） 是否允许为空 户 0) 不允许为空 户编号 00) 不允许为空 户名称 00) 不允许为空 款人 0) 不允许为空 化利率 2,6) 不允许为空 年天数 0) 不允许为空 息日 允许为空 息周期 ,2) 允许为空 息周期单位 0) 允许为空 始日期 允许为空 束日期 允许为空 用合同 许为空 第 3 章 系统设计 20 述 00) 允许为空 态 0) 不允许为空 部门信息表（ 列名 说明 类型（长度） 是否允许为空 门 0) 不允许为空 门名 称 00) 不允许为空 门主管 0) 不允许为空 门描述 00) 允许为空 系统用户信息表（ 列名 说明 类型（长度） 是否允许为空 户 0) 不允许为空 户名称 00) 不允许为空 户编号 00) 不允许为空 户密码 00) 允许为空 户电话 0) 户邮箱 0) 户部门 0) 户职务 0) 系统菜单表（ 列名 说明 类型（长度） 是否允许为空 单 0) 不允许为空 单 名称 00) 不允许为空 单类型 0) 不允许为空 级菜单 0) 允许为空 菜单权限表（ 列名 说明 类型（长度） 是否允许为空 限 0) 不允许为空 单 0) 不允许为空 户 0) 不允许为空 系统日志表（ 列名 说明 类型（长度） 是否允许为空 限 0) 不允许 为空 单 0) 不允许为空 户 0) 不允许为空 目 0) 允许为空 作时间 允许为空 户 址 00) 不允许为空 审批流程信息表（ 第 3 章 系统设计 21 列名 说明 类型（长度） 是否允许为空 程 0) 不允许为空 程名称 00) 不允许为空 批流程