电信业务数据稽核管理系统的设计与实现_第1页
电信业务数据稽核管理系统的设计与实现_第2页
电信业务数据稽核管理系统的设计与实现_第3页
电信业务数据稽核管理系统的设计与实现_第4页
电信业务数据稽核管理系统的设计与实现_第5页
已阅读5页,还剩87页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

说明 1. 本文仅作为工程硕士论文格式排版范文使用,论文内容不做为优秀论文使用。如有和软件工程硕士论文规范冲突的地方以规范为准。2. 本页非论文正式内容,正式内容从下页开始。分类号:TP311 单位代码:10422密 级: 学 号:200412671硕士学位论文论文题目: 电信业务数据稽核管理系统的设计与实现作者姓名 周波 专 业 软件工程 导 师 合作导师 2012年10月10日原创性声明和关于论文使用授权的说明原创性声明本人郑重声明:所呈交的学位论文,是本人在导师的指导下,独立进行研究所取得的成果。除文中已经注明引用的内容外,本论文不包含任何其他个人或集体已经发表或撰写过的科研成果。对本文的研究作出重要贡献的个人和集体,均已在文中以明确方式标明。本声明的法律责任由本人承担。论文作者签名: 日期: 关于学位论文使用授权的声明本人完全了解山东大学有关保留、使用学位论文的规定,同意学校保留或向国家有关部门或机构送交论文的复印件和电子版,允许论文被查阅和借阅;本人授权山东大学可以将本学位论文的全部或部分内容编入有关数据库进行检索,可以采用影印、缩印或其他复制手段保存论文和汇编本学位论文。(保密论文在解密后应遵守此规定)论文作者签名: 导师签名: 日期: 目 录目 录ICONTENTSIII摘 要VABSTRACTVII第1章 绪论81.1 系统开发背景81.2 国内外研究现状91.3 解决的主要问题91.4 本文的主要工作101.5 论文的组织结构10第2章 电信业务数据稽核管理系统需求分析122.1 总体业务描述122.2 系统目标和解决的问题142.3 系统需求问题描述152.3.1系统功能性需求152.3.2系统非功能性需求27第3章 系统设计293.1系统技术架构303.2 系统功能架构313.2.1 系统功能组成31第4章 系统详细设计334.1 系统建模334.1.1 系统的整体模型结构334.2 详细设计分析344.2.1 扫描模块详细设计344.2.2定单稽核的详细设计374.2.3专项稽核的详细设计384.3系统接口设计404.4系统数据库设计43第5章 系统实现与测试475.1开发环境:475.2系统实现:47第6章 结论与展望77参考文献79致 谢81CONTENTSChinese AbstractiEnglish AbstractiiiChapter 1 Introduction71.1 Development background for the audit system of telcom business71.2 The latest state of technology81.3 The main problems need to be resolved in this paper81.4 The main work of this paper91.5 The structure of this paper9Chapter 2 The requirement analysis of the audit system of telcom business112.1 Introduction to the audit system of telcom business112.2 Project goal of the audit system of telcom business122.3 The discription of requirement for the audit system of telcom business132.3.1 Functional requirement132.3.2 Non- functional requirement25Chapter 3 Construction design for the audit system of telcom business263.1 Desing aim and principle for this system263.2 Technology construction design273.2.1 Technology construction for the audit system of telcom business27Chapter 4 Detail design for the audit system of telcom business294.1 System modeling for the audit system of telcom business294.1.1 Model structure of this system294.1.2 The whole structure of this system364.2 Model design of this system304.2.1 The detail design for the otherness management304.2.2 The detail design for the integrative management33Chapter 5 Implement and test for the audit system of telcom business435.1 The whole implement for the audit system of telcom business42Chapter 6 Conclusion43Referrences44Acknowledgements45摘 要电信重组后市场竞争日趋激烈,各个运营商为提升市场竞争力,推出大量捆绑业务和组合产品,资费下调、利润空间减少,运营商在控制成本的同时,更加注重保障收入的完整,同时业务复杂度显著增加,由于系统限制不足和人为因素,经常会出现业务违规办理的情况,导致各种错收漏收。另一方面,由于业务数据涉及多个平台,各平台之间存在频繁数据交互,因系统问题等因素会导致平台间出现数据的不一致的情况,影响用户服务和收入准确性。由于电信业竞争激烈,导致运营商纷纷下调资费,利润空间减少;因此各运营商在控制成本的同时更加注重收入确保。加强内控管理,确保业务受理的规范性和合理性,保障收入完整,成为运营商一项非常重要的工作。电信业务数据稽核管理系统是近年兴起的运营商对企业业务数据进行稽核管理的有效工具。它通过系统对各平台间的数据一致性和业务合规性进行校验,并对异常数据进行闭环派单整改,确保业务数据的准确性、完整性和一致性,实现了业务稽核工作的电子化、流程化、自动化管理,大大降低了稽核工作的人工成本和复杂程度,提高了相关工作效率,确保了稽核工作的全面性和准确性,为收入保障和内控工作提供了强有力的支撑,从而有效避免收入流失和各类服务问题,并以此为手段来提高企业的获利能力、收入以及客户满意度。本文通过分析电信业务数据稽核管理的实际需求和业务流程,设计和实现了一个针电信行业的业务数据稽核管理系统。首先,本文在讨论电信业务数据稽核管理系统项目背景和对其开发设计所面对问题的基础上,分析了系统的功能需求和非功能性需求,并对系统需求以流程图和用例图的形式来详细说明。在需求分析基础上,我们进行了电信业务数据稽核管理系统架构设计。首先根据系统需求提出系统设计目标和原则,然后分别对系统技术架构和功能架构进行了设计。技术架构主要考虑系统的可扩展性,可维护性以及性能问题。再一步进行电信业务数据稽核管理系统的详细设计。该部分对各个模块的设计进行了描述。第四部分在详细设计的基础上,首先对各个模块的实现进行了简单介绍,给出了系统的整体效果图和各个部分的实现。最后,本文对电信业务数据稽核管理系统的应用情况作了简单介绍,并对系统进一步改进提出了建议。综上所述,我们在分析业务需求和客户关系管理思想的基础上,设计并实现了电信业务数据稽核管理系统。关键字:电信行业,业务数据稽核,软件工程 ABSTRACT Keyword: Telecommunications,Telecom Business Data Auditing,Software engineering第1章 绪论1.1 系统开发背景当前电信行业营业规模、收入总量迅速扩大,光纤宽带、3G、移动增值等业务快速增长,各个运营商开始向综合信息服务提供商转型,提供的产品及业务种类显著增加。另一方面,电信重组后市场竞争日趋激烈,各个运营商为提升市场竞争力,推出大量捆绑业务和组合产品,业务复杂度显著增加,因系统限制不足和人为因素,也会出现业务违规办理的情况,导致各种错收、漏收。另一方面,由于业务数据涉及多个平台,各平台之间存在频繁数据交互,因各种因素会导致数据的不一致的情况,影响用户服务和收入准确性。另一方面,电信行业竞争导致运营商纷纷下调资费,利润空间减少;因此各运营商在控制成本的同时更加注重保障收入完整。加强内控管理,确保业务受理的规范性和合理性,保障收入完整,成为运营商一项非常重要的工作。目前,运营商的业务数据稽核工作大都采用人工方式,通过人工检查来对各个业务环节的数据进行比对,查找漏洞进行补收。这种方式因人力有限,只能停留在受理资料完整性、用户是否欠费等浅层次的稽核工作上;无法做到深入分析各种业务规则漏洞,及时、全面、准确的稽核出各种违规业务数据。另外稽核出的异常数据全靠人工来调度整改,整改结果靠人工汇总上报,工作量极大且无法实现闭环管理,造成异常数据不能及时得到整改,不能够真正达到避免收入流失的效果。面对人工稽核的不完善带来的日益严重的收入流失的现状,亟需建设业务数据稽核系统,来自动实现对各类业务数据的一致性、合规性进行稽核,并对数据整改调度进行自动化、流程化、闭环管理。从而提高稽核的工作效率和稽核的全面性、准确性,加强收入保障,防范内控风险。1.2 国内外研究现状根据IDC、普华永道、RHK等国际知名咨询公司发表的报告,在全球50多家电信运营商中,约有三分之一的公司因计费或欺诈行为而蒙受重大损失,损失约占其年度总收入的5%15%。收入流失既严重影响企业经营业绩,又制约了企业的正常发展,因此各个运营商都已经开始高度重视收入保障工作,陆续开始建设业务数据稽核平台。目前国内已有平台主要实现了对异常业务数据的分析和提取,但是缺少对后续整改工作的流程管控,也未实现与业务流程的密切结合。同时电信业务具有复杂多变的特点,很多平台存在扩展性和灵活性不足的缺点,对后续新增业务的支持能力不够。1.3 解决的主要问题电信业务数据稽核管理系统是建立在整个电信业务系统基础上上的子系统,该系统通过生产系统获得业务数据,并根据事先配置好的稽核规则,对数据进行校验,生成存在异常的业务数据,并通过闭环的派单流程发送到责任部门进行整改,直至数据修正准确。系统必须具备以下特点:1、 系统必须实现对纸质定单的电子化,改变以往因稽核纸质定单,纸质定单传递耗时时间过长带来的稽核延时,提高稽核效率。2、 系统能够根据预先定义的规则进行自动化稽核。3、 针对电信业务复杂多变的特点,系统设计必须通用性强,具备高度扩展性。4、 系统必须与稽核业务流程高度结合,实现从异常数据生成、派单、整改、复核在内的全闭环管理,实现对电信业务稽核工作的全面支撑。5、 稽核内容全面,既包括对业务定单合规性的稽核,又包括计费收入数据稽核和平台间数据一致性稽核,覆盖收入保障的所有范围。6、 稽核过程需要对海量业务数据进行处理,处理能力必须高效,能够满足各类业务时限要求。如何设计满足以上需要的电信业务稽核管理系统是本文要解决的主要问题。1.4 本文的主要工作本文分析了电信业务数据稽核管理系统的实际需求和业务流程,并结合收入保障和数据稽核理论,设计和实现了电信业务数据稽核管理系统。首先,本文讨论了电信业务数据稽核管理系统项目背景和所面对问题,介绍了国内国际的系统现状。在此基础上分析了系统的稽核业务流程,进而分析系统的功能需求和非功能性需求,将系统需求以流程图和用例图的形式详细说明。在需求分析基础上,讨论电信业务稽核管理系统架构设计。首先根据系统需求提出系统设计的目标和原则,然后将架构设计分为系统技术架构和功能架构分别进行讨论。技术架构要求考虑系统的可扩展性,可维护性以及性能问题。在技术架构讨论中,首先分析了系统的网络架构和系统数据存储结构,然后在逻辑架构讨论中,分析了J2EE架构分层模型,并对各层的功能进行了分析。在功能架构分析中,讨论了系统各部分的功能组成,最后给出一个动态的系统功能流程。其次,进行电信业务数据稽核管理系统的详细设计。根据需求分析来设计系统,并对各个模块的设计进行了描述。在系统建模中,为了更加充分的理解系统的设计,我们简单介绍了电信业务系统总体架构,并分析了业务数据稽核管理系统在其中的作用和位置。然后给出了电信业务数据稽核管理系统的整体结构图。在了解了整体结构之后,介绍了各个模块的详细设计。在详细设计中,利用状态图和交互图进行设计分,给出了详细设计类图。再次,我们在详细设计的基础上,对各个模块的实现进行了介绍,给出了系统的效果图。在详细分析的最后,分析了系统测试,并对压力测试的环境搭建和测试过程进行了详细讨论。最后,本文对电信业务数据稽核管理系统的应用情况作了简单介绍,并对系统的设计和实现进行了总结,提出了对系统的展望和改进建议。1.5 论文的组织结构第1章绪论,主要描述系统的开发背景、业务数据稽核管理的国内外现状,本文解决的主要问题和完成的工作。第2章系统需求分析,主要进行系统的需求分析。首先进行了电信业务数据稽核管理系统的概述。其次描述了该系统的系统目标和解决的问题。最后对需求分析按照功能需求和非功能需求两个类别进行描述。第3章系统架构设计,主要进行系统的架构设计。首先对系统的设计目标和原则进行了阐述。其次,在技术架构设计中,分别按照物理架构和逻辑架构进行设计。最后详细描述了系统功能架构的设计过程。第4章系统详细设计,本章主要进行系统的详细设计。首先在系统建模部分,在对电信业务系统整体模型结构描述的基础上,对电信业务数据稽核系统的整体结构进行设计。其次进行了各个模块的详细设计。第5章系统实现与测试,首先描述了系统的整体实现,并对各个模块的实现进行了描述。其次本章描述了系统测试的情况,并对压力测试进行了详细描述。第6章对论文进行了总结,并对系统的进一步提升提出了改进意见。第2章 电信业务数据稽核管理系统需求分析2.1 总体业务描述电信业务数据稽核是收入保障管理的主要工作,内容涉及从业务受理、服务开通、计费账务全业务流程,需要各级业务、职能管理部门全面参与。电信业务数据稽核管理系统包括业务定单稽核子系统、平台数据稽核子系统、专项稽核子系统、整改派单子系统;每个子系统又包含多个功能模块。各个子系统的主要业务描述如下:一、 档案扫描子系统实现用户证件和定单的扫描上传,扫描件用于对用户签字和证件进行稽核以及实现纸质档案的电子化;在处理客户与受理相关的投诉时,可以在线(内部办公网络)实时通过定单号、证件号快速查询定单和证件的扫描件。二、 业务定单稽核二级稽核人员对证件、定单扫描件以及所有定单业务办理的合规性进行稽核,对存在问题的定单派单到相应营业厅进行整改;营业员整改完毕后,二级稽核人员对整改结果进行复核,市公司市场销售部的三级稽核人员则对全市定单稽核和整改情况进行抽查,对发现存在问题的定单派单到二级稽核进行处理整改,二级稽核根据实际具体差错进行相应的整改处理或继续派单到营业厅进行整改。业务定单稽核子系统实现了对上述稽核过程的电子化、实时化、系统流程化管理,主要包括定单多条件组合筛选及导出、定单稽核(批量稽核、循环稽核)、差错整改、整改复核、三级稽核模块、吉祥号管理(动态配置吉祥号规则进行吉祥号定单稽核提取)。三、 平台数据稽核子系统平台数据稽核子系统主要包括自动核对模块(固话核对模块、宽带核对模块、移网核对模块)、数据关联集中展现模块、数据定时自动同步模块。1、对固话、宽带、2G、3G在业务系统中的数据和相应平台间的数据进行一致性比对,核对内容包括号码是否存在、功能服务是否一致、费用账期是否合规等;提取差异安排相关责任进行部门整改。2、以受理定单号作为入口提取各平台相关数据,进行集中展现,解决了人工查询需要各系统切换的繁琐。3、定时自动同步部分核心数据,提高基础信息一致性(如为保证登陆工号、部门一致性:每天定时同步员工表、部门表、产品表、动作表等)。四、 专项稽核子系统根据收入保障的相关要求,针对特定可能存在的业务漏洞,制定相应稽核规则,检查出存在问题的用户数据,并组织专项整改。五、 派单整改子系统各稽核子模块生成的差异数据通过派单整改子系统派单到职能部门进行审核,审核通过后发送责任部门进行整改,整改完毕后对结果进行复核,复核通过后流程结束,实现业务数据稽核整改的全闭环管理。六、 统计查询主要提供档案扫描统计查询、定单稽核统计查询、专项稽核统计、差错受理统计、稽核超时统计、差错整改统计等功能。七、 系统管理主要实现对稽核参数进行配置;分配用户权限;稽核人员稽核范围配置等;包括:公告管理、日志管理、专项稽核接口管理、自动稽核接口管理、角色管理、密码管理等。关于上述七个子系统的详细功能框架,将在系统需求分析一章中给予详细说明。2.2 系统目标和解决的问题系统设计和实现达到以下目标:1 实现对客户定单、证件的扫描上传,对受理定单、客户签字、证件的电子化查询和稽核,避免纸质定单人工传递带来的稽核延时及查询的不便性。2 实现对业务定单的自动化稽核,对业务受理的合规性进行自动检查,对不需人工复核的定单自动通过或退回,减去人工稽核工作量,实现定单稽核的全面性,避免因抽查造成的漏检情况。3 实现对用户数据的自动化稽核,对业务系统数据与交换网元数据进行一致性和完整性检查,对不一致或缺失的部分进行报错并提醒,稽核人员可以只对报错部分进行针对性的稽核,提高稽核效率。4 系统提供工单处理流程,对异常数据根据业务需要分解和流转到相关部门处理。通过工单在各环节间流转来完成数据整改工作跨部门的配合和连接。5 系统实现对稽核规则和工单流程的配置化管理,可根据实际业务逻辑的变化通过配置接口界面调整实际的稽核规则和工单处理流程,实现调整的快速化、简单化。6 系统应提供全面的统计分析和考核功能,系统必须在每次稽核后,对数据采集、数据稽核、工单处理、数据整改等提供相应的日、周、月统计报表。所有统计报表,均需要提供表格和图表方式进行综合呈现。对所有稽核结果形成按照市、区县、乡镇营业部维度和业务维度的统计报表,以便对相关部门的差错和整改情况及进行考核。2.3 系统需求问题描述2.3.1系统功能性需求1. 系统涉及的岗位需求 业务数据稽核系统涉及的岗位如图2-3所示:图 2-3 业务数据稽核系统岗位如上图所示,每个岗位对应着不同的操作职责和权限,分别如下:(1) 营业人员对应的职责有:定单扫描、证件扫描、受理差错整改。用例图如下:(2) 二级稽核人员对应的岗位职责有:定单二级稽核、受理差错整改情况复核、专项稽核差错整改。用例图如下:(3) 三级稽核人员对应的岗位职责有:定单三级稽核、专项稽核派单、专项稽核整改复核。用例图如下:(4) 系统管理员职责有:工号管理、权限管理、稽核点配置。(5) 专项稽核配置人员职责:专项稽核规则配置、专项稽核任务执行。(6) 平台维护人员职责:负责平台异常数据的核查整改工作。2.业务流程及用例在分析了系统的岗位设置之后,本文分业务档案扫描、业务定单稽核、平台一致性稽核、专项稽核、派单整改、统计分析、系统管理六部分来整理系统需求。(1) 档案扫描子系统档案扫描子系统包括证件扫描、定单扫描、协议扫描三个功能模块,证件及定单扫描的处理流程如下图所示: 用户到前台进行业务办理,营业员首先对证件进行扫描上传,然后为用户在系统中办理相关业务,打印受理定单,用户签字后,收取相关费用,业务办理完毕,然后对定单进行扫描。 证件扫描模块菜单名称证件预扫描适用角色范围 营业员 二级稽核 稽核班长 三级稽核 专项稽核调度 专项稽核处理 稽核逻辑开发 系统管理员 公共查询目的当受理单未进入稽核系统,或者遇到业务较多来不及逐笔扫描定单,或者客户需要着急走不能等待的情况下,可以预先扫描并保存客户证件(也需要考虑方案支持拍照,目前高拍仪正在测试中)功能要求1. 能够初始化扫描仪2. 扫描的证件可以记入登录者本人名下(默认),也可以记入本营业厅其他营业员名下(可以下拉框选择)3. 扫描件最多可以上传6份4. 扫描时选择扫描件的类型,包括:身份证(单张)、身份证(用户/经办人)、驾照、护照、户口簿、a4(其它)5. 扫描后的证件保存在服务器上并记录该证件属于哪个工号其他要求证件扫描上传后系统需要在证件的图片上加上水印(chinaunicom 扫描件的时间),以确保扫描件符合市公司要求,即证件只能在同一天、同一营业员、同一客户使用,二级稽核可以在稽核环节看到水印人工判断定单扫描模块模块名称定单扫描适用角色范围 营业员 二级稽核 稽核班长 三级稽核 专项稽核调度 专项稽核处理 稽核逻辑开发 系统管理员 公共查询目的对于从生产系统进入了稽核系统的工单,进行定单及证件等纸质凭证的扫描。功能要求1. 本菜单打开后能够默认显示本登录工号下的所有未扫描的工单,显示的信息包括:流水号、服务号码、业务类型,并显示以下凭证是否扫描:客户证件、业务定单、 其他证件(包含经办人、担保人、付费人的证件)、费用减免依据(包括协议、营销方案申请、签字减免等纸质凭证)、其他2. 也可以按照流水号,单个查询3. 可以初始化扫描仪4. 可以打开某个定单,然后扫描该定单的客户证件、业务定单、 其他证件(包含经办人、担保人、付费人的证件)、费用减免依据(包括协议、营销方案申请、签字减免等纸质凭证)、其他5. 除业务单外的其他证件信息,可以现扫描也可以从自己已经预扫描过的证件里面选择6. 业务定单能够支持扫描、复印、拍照7. 如果是关联业务的话,不用重复扫描,扫描完一笔定单(作为主单)后其他定单可以直接通过输入主单流水号而共享扫描件。输入主单流水号的时候需要有以下限制条件:1) 主单流水号不能与当前流水号相同2) 主单流水号必须已经提交给二级稽核了3) 主单流水号必须与当前流水号的业务是同一受理人、同一天、同一业务类型、同一网别8. 可以输入备注9. 可以输入营销方案申请、合同会签的协议或者签字流程的OA编号10. 支持暂存、保存提交,保存提交是指的该定单扫描件已经全了可以提交给二级稽核11. 打开定单除了能够扫描外,还能够显示该定单的定单操作历史日志,包括:顺序、处理人、动作、处理时间、所属部门、处理意见(结果)其他要求1. 无法扫描情况的处理:针对部分代理商或营业点没有扫描仪或者扫描仪故障超过3天以上不能扫描上传的情况, 在营业员扫描业务单的地方可以选择“扫描”或“复印”。默认是扫描,即默认是需要扫描上传业务单的,但是如果部分代理商或营业点没有扫描仪或者扫描仪故障超过3天以上不能扫描上传的情况,可以选择复印,营业员办理业务时复印用户证件,粘贴在定单后面。在营业员扫描定单的操作界面,点击复印选项(一般默认为扫描定单),此类定单系统允许在无关联定单、无任何扫描件的情况下上传提交至二级稽核。但是如果没有选择复印,则在保存提交的时候系统需要验证:“必须扫描客户证件!或与其他定单相关联”2. 合并打印的关联提交对于像沃家庭这样一笔 多笔流水的情况,融合系统允许多张业务单合并打印到一张上去,这样扫描上传只需要在沃家庭主单上扫描上传一份即可,其他流水的单子就不需要扫描上传。因此,需要加一个功能:如果是标志为合并打印的,允许有一笔主单扫描上传后提交,其他同一定单号下面的其他所有流水号批量关联上传。3.定单关联模块菜单名称批量定单关联适用角色范围 营业员 二级稽核 稽核班长 三级稽核 专项稽核调度 专项稽核处理 稽核逻辑开发 系统管理员 公共查询目的对同一工号受理的扫描件可以共享,或者只需要一个主单提供扫描件其他被关联单不需要提供扫描件的情况,对这种定单进行批量的关联功能要求1. 输入或选择一个主关联定单号,需要有如下限制条件:主关联定单只能是已经扫描并提交的定单,在主单可供选择的界面中也应该显示的是已经扫描并提交的定单2. 选择被关联定单,需要有如下限制条件:1) 被关联单必须是未提交的定单2) 主关联单与被关联单必须是同一受理人、受理时间在同一天、同一业务类型、同一网别3. 关联后的所有单子就统一批量提交给二级稽核了。4. 按时间段可以该营业员名下选择没有提交过的定单5. 通过复选框选择可以关联的定单进行关联,支持全选、重置6. 单次关联定单数=100笔其他要求批量定单关联的需要系统加上批量定单关联的标志,需要能区分出哪个是主单、哪些是与这个主单关联的被关联单(2)定单稽核子系统 稽核规则配置能够根据业务变动灵活配置新稽核规则,稽核业务逻辑与系统界面分离,实现松耦合管理,提高系统可扩展性。自动稽核每天晚上业务系统的数据会被同步到省公司统一提供的查询数据库,业务稽核管理系统将所需数据从查询数据库中抽取本地,然后根据事先配置好的稽核规则执行自动稽核任务,生成异常数据,异常数据包括差错类别,差错描述等信息。辅助稽核可根据稽核人员指定的条件,提取需要稽核定单的与稽核相关的关键信息,如客户信息、用户信息、账务信息等。相关信息可导出EXCEL表,用于辅助稽核。稽核完毕后可填写稽核结果,选择差错种类并对差错进行描述。菜单名称等待稽核定单适用角色范围 营业员 二级稽核 稽核班长 三级稽核 专项稽核调度 专项稽核处理 稽核逻辑开发 系统管理员 公共查询目的二级稽核对营业员提交上来的、且竣工后的定单进行稽核功能需求1. 可以通过查询条件查询出该二级稽核人员管辖的稽核范围内的所有未稽核的定单2. 可以点击打开查看单笔定单详情3. 系统自动稽核的结果显示在定单详情里面4. 可以导出查询出来的定单的信息,导出时需要哪些字段可以手工选择5. 可以单笔稽核通过或退回(包括通过、通过并继续、退回、退回并继续、跳过暂缓稽核)6. 可以多笔定单通过退回,界面功能包括:全选、取消全选、当页批量通过、当页批量退回、全部批量通过、关联批量通过(主单通过,与主单关联的单子也一并通过)、关联批量退回(主单退回,与主单关联的单子也一并退回)7. 增加一个查询条件“是否批量关联”,如果选择“是”可以查询出所有批量关联定单的主单的信息, 点击主单后弹出定单详情界面时,定单详情界面上增加一个可以查看所有被关联单信息的地方。如果点击查看被关联单,则可以看到被关联定单的列表,再点击某个定单,可以进入看到该定单的定单详情查询条件定单号、流水号、网别、业务类型、品牌、产品(套餐)、自检状态、三级部门、受理部门、受理人、时间范围(指的是受理时间)、是否上传(含有以下项目:全部(默认的)、已上传、未上传)、受理系统(含有以下项目:E侧、B侧)、是否批量关联(是、否)/*有关联标志的*/、定单形式(全部定单、扫描定单、纸质定单 /*指的是无扫描仪或扫描仪损坏的情况下纸质报送的部分*/)、 查询结果在界面上展示的信息定单号(按定单号排序)、流水号、服务号码、关联号、业务类型、产品、客户名、受理人、受理部门、自检(自检通过、自检差错、辅助稽核通过、辅助稽核差错),以下信息显示是否扫描即可:客户证件、业务定单、 其他证件(包含经办人、担保人、付费人的证件)、费用减免依据(包括协议、营销方案申请、签字减免等纸质凭证)、其他导出和每个定单的详细信息需要的字段定单号(按订单号排序)、流水号、业务号码、业务类型、账户标识、网别、品牌、新产品名称、原产品名称、受理点、受理人、受理工号、新客户名称、原客户名称、证件号码、证件类型、证件地址、原装机地址、装机地址、联系、联系电话、用户类型、用户性质、营业费用、预存款、押金、付费方式、原速率、新速率、新增优惠、取消优惠、新增服务、取消服务、用户关系变化(新增)、用户关系变化(取消)、sp信息(新增和取消)、付费关系信息(新增和取消)、帐务优惠信息(新增和取消)、欠费金额、实时结余、备注、吉祥号码类型、自检差错信息、是否上传、协议编号、 单笔定单需要显示的定单详情流水号、业务号码、受理人、受理点、产品、业务类型;以下扫描件:业务定单、客户证件、其他证件(包含经办人、担保人、付费人的证件)、费用减免依据(包括协议、营销方案申请、签字减免等纸质凭证)、其他;扫描件可以放大查看,也可以打印。关联定单号、自检信息、扫描提交备注、二级稽核退回原因(输入文本框)、差错类型(可选择,可配置);定单操作历史日志:顺序、处理人、动作、处理时间、所属部门、处理意见(或结果)其他要求差错处理营业人员可查看差错定单,并对差错进行整改,整改完毕后填写整改结果。菜单名称定单稽核差错处理适用角色范围 营业员 二级稽核 稽核班长 三级稽核 专项稽核调度 专项稽核处理 稽核逻辑开发 系统管理员 公共查询目的营业员对二级稽核人员稽核出差错被退回的定单进行整改处理功能需求1. 显示本工号被退回的所有定单信息:流水号、服务号码、业务类型、产品、客户名、自检(自检通过、自检差错、辅助稽核通过、辅助稽核差错),以下信息显示是否扫描即可:客户证件、业务定单、 其他证件(包含经办人、担保人、付费人的证件)、费用减免依据(包括协议、营销方案申请、签字减免等纸质凭证)、其他2. 可以手工刷新、定时刷新3. 可以按照流水号单笔查询4. 可以点击打开查看单笔定单详情5. 对某笔定单进行证件、定单等凭证的重新上传,也可以记录差错整改的情况单笔定单需要显示的定单详情流水号、业务号码、受理人、受理点、产品、业务类型;以下扫描件:业务定单、客户证件、其他证件(包含经办人、担保人、付费人的证件)、费用减免依据(包括协议、营销方案申请、签字减免等纸质凭证)、其他;关联定单号、自检信息、扫描提交备注、稽核退回原因、差错类型(可选择、可配置);定单操作历史日志:顺序、处理人、动作、处理时间、所属部门、处理意见(或结果)其他要求扫描件可以放大查看,也可以打印整改复核二级稽核人员查看整改结果,对营业员整改情况进行复核,对存在问题的进行退单继续整改,对整改完毕的复核通过。模块名称整改复核适用角色范围 营业员 二级稽核 稽核班长 三级稽核 专项稽核调度 专项稽核处理 稽核逻辑开发 系统管理员 公共查询目的二级稽核退回的差错定单营业员整改后再次提交的定单,二级稽核进行复核功能需求1. 界面上默认显示本月营业员整改后再次提交所有定单2. 可以通过流水号查询单笔定单,也可以通过时间范围等信息查询多笔定单3. 可以点击打开查看单笔定单详情4. 对于二次提交的单笔定单可以填写二级稽核退回原因,可以对这笔定单进行通过(包含通过并继续)、退回(包含退回并继续)、跳过暂缓稽核处理5. 也可以对多笔进行通过或退回处理,包括:全选、取消全选、当页批量通过、当页批量退回、全部批量通过、关联批量通过(主单通过,与主单关联的单子也一并通过)、关联批量退回(主单退回,与主单关联的单子也一并退回)查询条件流水号、网别、业务类型、品牌、产品、受理部门、时间范围查询结果在界面上展示的信息定单号(按定单号排序)、流水号、服务号码、关联号、业务类型、产品、客户名、受理人、受理部门、自检(自检通过、自检差错、辅助稽核通过、辅助稽核差错),以下信息显示是否扫描即可:客户证件、业务定单、 其他证件(包含经办人、担保人、付费人的证件)、费用减免依据(包括协议、营销方案申请、签字减免等纸质凭证)、其他单笔定单需要显示的定单详情流水号、业务号码、受理人、受理点、产品、业务类型;以下扫描件:业务定单、客户证件、其他证件(包含经办人、担保人、付费人的证件)、费用减免依据(包括协议、营销方案申请、签字减免等纸质凭证)、其他;扫描件可以放大查看,也可以打印。关联定单号、自检信息、扫描提交备注、二级稽核退回原因(输入文本框)、差错类型(可选择,可配置);定单操作历史日志:顺序、处理人、动作、处理时间、所属部门、处理意见(或结果)其他要求(3)平台数据稽核子系统 主要实现对固话业务、小灵通业务、宽带业务、GSM业务的客户资料数据与相应平台数据进行比对;生成差异结果,并通派单子系统完成下发、整改、反馈等。平台数据稽核子系统分为以下两个模块: 计划任务定制管理模块系统应支持计划性的任务管理,能够对采集、稽核、工单等进行任务定制。计划任务定制应能灵活选择需要稽核的数据源业务系统、数据源业务属性以及稽核规则等项目,且各项目可以灵活组合形成一个完整的计划任务。计划任务管理应支持多任务的并行执行机制,使多任务能够并行执行,提高系统的运行效率。系统支持年、月工作计划的制定与审核,工作计划是任务的集合,系统应该能够按月、按年等粒度,统计工作计划完成的全面性和及时性。数据采集和校验模块稽核数据范围包括以下平台和系统:1固话交换机平台:2宽带业务平台(亚信平台等)3智能网平台4HLR(西门子、华为、贝尔等)5OCS系统数据采集应该具备以下功能:1数据采集应能根据采集请求,向业务支撑系统或网元提取原始数据,并进行数据的完整性校验。2系统应提供对采集任务进行配置的功能,包括采集周期、采集启动时间以及采集任务对应的脚本等。3系统应能对采集情况进行跟踪,可查询历史采集任务的原始交互日志,了解采集任务执行情况。4必须支持对数据的过滤、清洗、比对的功能,能够根据实际数据情况对数据进行多重的数据处理。数据校验应具备以下功能:1数据稽核行为必须是可自定义的,能够通过界面的配置化进行业务的扩充。2数据的稽核应该支持上百万级别的数据量的比对工作。数据稽核应支持多任务并发。数据稽核应在2小时内完成。3系统应能提供生成差异性报告的功能,并提供差异结果导出功能。4稽核结果展现应包括各相关平台的具体差异信息,以及比对数据的所有相关属性。2.3.2系统非功能性需求1. 可靠性(1) 排除人为误操作因素,由应用系统自身原因导致的系统崩溃故障,平均无故障时间(MTBF)应大于90天,平均修复时间(MTTR)应小于4 小时。(2) 应用系统必须支持连续724 小时不间断地工作,应用软件中的任一构件更新、加载时,在不更新与上下构件的接口的前提下,不影响业务运转和服务。(3) 系统必须采用增量备份和全备份相结合的方式定期备份重要的系统数据。2. 易使用性(1) 应用系统必须提供一致性的图形用户界面风格。(2) 应用系统对普通用户的操作界面应该以B/S 方式实现。(3) 应用系统必须支持同时打开多个管理窗口以对不同任务进行并行的操作。3. 可维护性(1) 系统在运行过程中所发生的任何错误都应该有明确的错误编号,并能在系统的相应维护手册中查到错误处理方法与步骤。(2) 应用系统应该采用构件化设计思想,系统框架与业务逻辑分离;要求具备开放的体系结构。(3) 应用系统应该支持通过统一的图形界面能够访问到系统各构件、合约的版本信息及相应功能说明。(4) 应用系统必须支持各构件的单独升级,并应该尽可能实现在线升级功能。4. 可移植性(1) 应用系统应该不需改动或尽可能少的改动就可以在不同的主流UNIX(IBM、HP、SUN)及Linux 平台下方便的移植。(2) 应用系统必须支持客户端软件版本的自动升级。第3章 系统设计 系统设计是把用户需求转化为软件系统的最重要的技术开发环节,系统设计的好坏从根本上决定了软件系统的优劣,系统软件设计的核心内容包含以下5个方面:体系结构设计、用户界面设计、数据库设计、模块设计、数据结构设计和算法设计,帮助开发人员搞清楚“设计什么”和“如何设计”,系统设计过程划分为两个阶段:高层设计阶段和详细设计阶段。高层设计阶段的重点是体系结构设计,详细设计阶段的重点是用户界面设计、数据库设计、模块设计、数据结构设计和算法设计等。3.1 系统技术架构系统的体系机构应该满足“合适性、结构稳定性、可扩展性、可复用性”1、合适性,即体系结构应适应“功能性需求”和“非功能性需求。2、结构稳定性,体系结构一旦设计完成,应当在一定的时间内保持稳定不变,只有这样才能使后续工作顺利开展。3、可扩展性,是指软件扩展新功能的容易程度,可扩展的前提条件是“保持结构稳定”4、可复用性,应分析应用域的共性问题,然后设计出通用的体系架构模式,这样的体系机构才可被复用。为满足以上要求,本系统采用SSH架构,SSH 为 struts+spring+hibernate的一个集成框架,是目前较流行的一种Web应用程序开源框架。 集成SSH框架的系统从职责上分为四层:表示层、业务逻辑层、数据持久层和域模块层,以帮助开发人员在短期内搭建结构清晰、可复用性好、维护方便的Web应用程序。其中使用Struts作为系统的整体基础架构,负责MVC的分离,在Struts框架的模型部分,利用Hibernate框架对持久层提供支持,业务层用Spring支持。具体做法是:用面向对象的分析方法根据需求提出一些模型,将这些模型实现为基本的Java对象,然后编写基本的DAO(Data Access Objects)接口,并给出Hibernate的DAO实现,采用Hibernate架构实现的DAO类来实现Java类与数据库之间的转换和访问,最后由Spring完成业务逻辑。 系统的基本业务流程是: 在表示层中,首先通过JSP页面实现交互界面,负责传送请求(Request)和接收响应(Response),然后Struts根据配置文件(struts-config.xml)将ActionServlet接收到的Request委派给相应的Action处理。在业务层中,管理服务组件的Spring IoC容器负责向Action提供业务模型(Model)组件和该组件的协作对象数据处理(DAO)组件完成业务逻辑,并提供事务处理、缓冲池等容器组件以提升系统性能和保证数据的完整性。而在持久层中,则依赖于Hibernate的对象化映射和数据库交互,处理DAO组件请求的数据,并返回处理结果。 采用上述开发模型,不仅实现了视图、控制器与模型的彻底分离,而且还实现了业务逻辑层与持久层的分离。这样无论前端如何变化,模型层只需很少的改动,并且数据库的变化也不会对前端有所影响,大大提高了系统的可复用性。而且由于不同层之间耦合度小,有利于团队成员并行工作,大大提高了开发效率。系统的技术架构如下图所示: 图3-5 系统技术架构图3.2 系统功能架构3.2.1 系统功能组成电信业务数据稽核系统旨在实现电信业务数据稽核的自动化和整改的流程化,提高业务稽核工作的效率和质量。因此该系统必须包含与稽核工作相关的所有功能。结合实际情况,该系统应包含以下功能:(一)业务档案扫描管理;(二)定单稽核管理;(三)平台数据稽核;(四)专项稽核管理;(五)整改派单管理;(六)系统管理。通过初步分析,系统大致由业务档案扫描模块、定单稽核模块、专项稽核模块、整改派单管理模块、统计查询模块和系统管理模块几个子系统组成。由以上分析,我们获得系统的功能架构图,如图3-6所示 图3-6 系统功能架构图第4章 系统详细设计详细设计阶段是为每个模块完成的功能进行具体的描述,要把功能描述转变为精确的、结构化的过程描述。详细设计阶段常用的描述方式:流程图、N-S图、PAD图、伪代码等。4.1 系统建模4.1.1 系统的整体模型结构要完成联通电信业务数据稽核系统的设计,必须先了解联通业务系统的整体模型结构,该系统的整体模型结构如图4-1所示:图 4-1 联通业务系统的整体模型结构图由上图可以看出,ESS、BSS系统是联通核心业务系统,业务数据稽核管理系统从ESS系统的文件接口取得定单信息,从BSS备份库中取得业务数据,从固网交换平台和移网交换平台取得用户交换

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论