电子税务局毕业论文正稿

《电子税务局毕业论文正稿》由会员分享，可在线阅读，更多相关《电子税务局毕业论文正稿（95页珍藏版）》请在装配图网上搜索。

1、学校编码：10384 分类号密级_X UDC工 程 硕 士 学 位 论 文某市税收数据综合应用平台数据质量监控系统的设计与实现Design and Implementation ofData Quality Monitoring system forIntegrated Tax Data Application Platform 正东指 导 教 师：林凡副教授专 业 名 称：软件工程论文提交日期：20XX9月论文答辩日期：20XX9月学位授予日期：年月指 导 教 师：_答辩委员会主席：_2015年*月大学学位论文原创性声明本人呈交的学位论文是本人在导师指导下,独立完成的研究成果。本人在论文写作

2、中参考其他个人或集体已经发表的研究成果,均在文中以适当方式明确标明,并符合法律规和大学研究生学术活动规试行。另外,该学位论文为课题组的研究成果,获得 课题组经费或实验室的资助,在 实验室完成。请在以上括号填写课题或课题组负责人或实验室名称,未有此项声明容的,可以不作特别声明。声明人签名：年 月 日83 / 95大学学位论文著作权使用声明本人同意大学根据中华人民国学位条例暂行实施办法等规定保留和使用此学位论文,并向主管部门或其指定机构送交学位论文包括纸质版和电子版,允许学位论文进入大学图书馆及其数据库被查阅、借阅。本人同意大学将学位论文加入全国博士、硕士学位论文共建单位数据库进行检索,将学位论文

3、的标题和摘要汇编出版,采用影印、缩印或者其它方式合理复制学位论文。本学位论文属于： 1.经大学委员会审查核定的学位论文,于 年 月 日解密,解密后适用上述授权。2.不,适用上述授权。请在以上相应括号打或填上相应容。学位论文应是已经大学委员会审定过的学位论文,未经大学委员会审定的学位论文均为公开学位论文。此声明栏不填写的,默认为公开学位论文,均适用上述授权。 声明人签名：年 月 日摘 要税收征管和纳税服务是税收工作的两大核心业务。强化核心业务,关键在于提高税源管理水平。税源管理水平的高低,很大程度上取决于是否有效地解决两个不对称问题,即征纳双方之间的信息不对称、税务系统各部门之间的信息不对称问题

4、。这就要求税务部门首先要打通税务系统各部门之间的、税务系统和各经济主管单位之间的信息交互渠道,整合来至其他社会部门的涉税资源。并在此的基础上,从税收工作实际出发,强化税收情报综合分析能力,打破两个不对称的信息藩篱,从源头上提高税源管理效益。我国税务系统经过多年的信息化建设,尤其是金税工程的不断推进,基本实现了税收征管工作的数字化,但对海量税收数据的监、管、用缺乏全生命周期的规划,这成为税务部门有效发挥其职能作用的瓶颈。利用现代信息处理技术,强化涉税数据管理与应用,已成为各国税务部门提升税源管理水平的突破口。本文按照总局信息管税的总体要求,针对基层税务机关的开展税收征管和纳税服务工作实际需要,结

5、合某市国家税务局税收数据综合应用平台的建设思路和要求,利用数据仓库、数据挖掘等信息处理手段,进行分析挖掘等技术手段,对多种来源的涉税数据进行全生命周期的质量监督和管理,全力确保涉税信息采集数据、挖掘信息、发现规律、获取知识的税收数据分析利用链条的质量,提升税收数据信息和价值发现的有效性、可靠性,进一步发挥信息化建设对推进税收事业发展的支撑作用,推进征管体系现代化,服务经济、社会发展的新常态。具体用什么技术要概述一下关键词：税收数据综合应用平台；税源管理；信息不对称AbstractTax revenue collection and management are two of the mainb

6、usinesses of taxation work。To strengthen the core business, the key is to raise the level of tax source management. And the level of tax source management depends on whether we can solve two kinds of the information asymmetric problem or not. In another words, we need to solve the information asymme

7、try problem between the taxpayers and collection department, and between different departments in tax system. Hence, this requires us to make ways for information exchange between different departments in tax system and between the tax system and various economic unites,to integrate the tax resource

8、s from other social sectors. Given on that, we should Starting from the reality of tax work, strengthening the comprehensive analysis ability in tax information, breaking the obstacles of two asymmetric, so as to improve the efficiency of tax source management from the beginning.After years of infor

9、mation construction in our tax system, especially the continuing boosting of golden tax project, our county realizes the digitalization in tax collection work. But, for rapid development of social economic environment, it is still lack of overall plan of tax data monitoring, management and using wit

10、h the full data life-cycle, which becomes the bottleneck of effectively play functions in tax departments. So using modern information processing technology and strengthening the tax-related data management and application, has become the breach of the tax department to enhance the level of tax sour

11、ce management.? 缺33333Keywords: Tax Data Integrated Application Platform；Tax Source Management； Tax Data Monitoring目录摘要IAbstractII目录IV第1章绪论11.1项目开发的背景11.2国外研究现状综述31.3本文的研究方向及主要工作3第2章项目整体架构52.1项目定位与目标52.2项目设计原则52.4.1开放性与独立性统一原则52.4.2可持续发展原则62.4.3先进性与成熟性结合原则7第3章需求分析83.1项目需求综述83.2业务需求83.2.1查询统计83.2.2报表

12、管理93.2.3报告管理93.2.4OLAP分析93.2.5数据挖掘应用93.3技术需求103.3.1框架需求103.3.2性能需求113.3.3可扩展性需求113.3.4可操作性需求113.3.5可靠性需求123.3.6数据需求123.3.7数据应用对象需求123.3.8外部接口需求133.3.9其他技术需求13第4章概要设计144.1总体框架设计144.2数据架构设计154.3应用架构设计164.4非功能设计184.4.1性能设计184.4.2可靠性设计184.4.3可维护性设计20第5章数据支撑层的详细设计与实现245.1数据支撑层架构规划245.1.1生产系统数据层245.1.2数据仓

13、库层255.1.3分析应用系统层365.2数据模型的设计与实现375.2.1数据层次模型375.2.2历史区385.2.3原子区385.2.4汇总层395.2.5主题数据概念模型405.2.6逻辑模型实例405.2.7模型管理工具495.3数据的抽取、转换和加载545.3.1总体设计545.3.2数据同步545.3.3OT-ETL545.3.4数据加工565.3.5数据反馈57第6章应用支撑层的详细设计与实现586.1应用层总体架构586.2应用支撑功能模块定义596.3应用支撑层的实现606.3.1业务语义层设计626.3.2分析引擎设计636.3.3通用分析工具设计63第7章重点功能模块设

14、计与实现647.1一户式管理子系统647.1.1一户式整体设计647.1.2逻辑结构647.1.3一户式首页657.1.4一户式查询统计727.1.5界面设计与实现747.2收入分析767.2.1领导驾驶舱设计767.2.2税源地图77第8章项目测试798.1测试目标798.2测试规划及方案798.3测试准备808.4测试容与结果808.4.1数据和数据库完整性测试808.4.2接口测试808.4.3功能测试818.4.4性能测试828.5测试结果分析87第9章总结与展望889.1总结889.2展望88参考文献90致92第1章 绪论1.1 项目开发的背景经济决定税收,税收影响经济。近年来,经济

15、的发展逐渐呈现出从要素驱动、投资驱动转向创新驱动的新常态1。作为和经济密切相关的税收工作,也必然会呈现出。在社会经济走向新常态的过程中,与之密切相关的税收工作将会面临更多的挑战。目前,我国的税制结构仍然以间接税为主,在由10%左右的高速经济增长向7%左右的中高速经济增长新常态转变的过程中2,税收增长率的减速幅度通常会大于经济增长率的减速幅度。同时,经济结构变化必然带来税源结构的深刻变化。一方面,经济实体的组织形式、经营方式不断增加,发展速度不断加快3。税源呈现出复杂性、隐蔽性和流动性越来越突出、越来越普遍的特点4。另一方面,随着房地产税等涉及个人的直接税改革的推进,纳税人的围将在现有企业、个体

16、工商户的基础上增加自然人,纳税人数量将从大量变成海量；其高容量Volume、多样性Variety、速度Velocity及价值Value的4V特性5,直接导致了税务部门的数据来源更加广泛、数据类型多种多样。这使得各级税务机关如何更加有效的监、管、用税收信息,持续提高涉税数据质量的问题逐渐显现出来。同时,在税收新常态下,我国税务系统不断加强税收征收管理信息系统的现代化建设7。金税三期工程的推广建设,一是在全国税务系统的围,包括国税系统和地方税务系统,规了涉税数据的采集、处理和管理机制,为信息分析利用准备了数据基础；二是金税三期工程主体系统在国家税务总局、国税系统和地税系统的全面应用,实现了全国税收

17、管理信息系统的统一,为大围的涉税信息分析利用提供了技术条件；三是全国、省级数据大集中、涉税数据分类管和统一的税收征管工作要求,为信息分析利用整合了统一的管理体系8。综上所述,现阶段,我国税务系统既存在强化税收数据质量监督、规涉税数据使用的在要求,也具备了深度分析利用涉税数据所需的物质基础、技术条件和管理体系。1.2 研究现状和问题西方国家,如美国、德国、日本、意大利、澳大利亚等国家,税收信息化建设起步早、发展快、历时长、技术沉淀和经验积累深厚,已经逐渐从简单的统计分析发展到有理论支撑、技术先进、管理配套的现代税收数据质量管控系统。例如,美国联邦税务局IRS通过两个全国性的总部计算机中心和10个

18、区域性的大区服务中心实现了税收数据的高度管理,在进行业务管理、实现有效的税源管理、征收率高达80%以上的同时,税收直接成本下降到0.4%左右6。我国税收信息化建设走过了以业务处理为主的、以单机使用、税网/新税网、省级集中为标志的信息化建设历程,进入了以金税三期为标志的业务处理系统和决策支持并重、统一系统、统一流程、统一数据、全国涉税数据总局/省局两级集中的新的发展阶段。全国各级税务部门在不断探索数据分析和税源管理工作的过程中,都对如何通过技术手段提高数据质量的问题进行了不断的研究和实践。例如,XX国税利用税收数据综合应用平台,整合了金税三期系统数据、防伪税控系统数据、车辆购置数据以及工商、海关

19、、质检、能源、交通、公安等多个部门的涉税,通过多方比对的方式排除疑点,提高数据质量。但是,由于局限于当时现实条件,涉税数据质量的管理能力和效率都较为有限,无法满足新常态下经济社会发展对税收工作提出的时代要求。1.3 本文的研究方向及主要工作本文按照总局以信息管税为依托,努力构建税源专业化管理新体系9的总体思路,立足金税三期系统,借鉴其他行业对业务数据质量管控的实践经验,针对涉税数据质量管理没人管、没法管等问题,在某市国家税务局税收数据综合应用平台的整体框架下,从各种来源的涉税数据的采集、整理、保存、流转、使用等多个环节入手,？利用 、 等现代信息处理技术,采用。的手段,不断丰富涉税数据质量的跟

20、踪监控手段,预警数据使用风险,完善涉税信息采集数据、挖掘信息、发现规律、获取知识的分析利用链条,进一步发挥信息化建设对推进税收事业发展的支撑作用。本项目是XX市国家税务局强化数据质量管控、深化数据分析利用,努力适应税收工作新常态的一次新的尝试和努力补充后面的章节安排。要补充一下具体技术内容大概200字1.4 本文的组织结构第1章是绪论。从部原因和外部原因,既经济发展新常态和税收工作新常态,两个方面分析了税收数据质量管控的必要性和可行性,介绍了当前研究的概况以及主要的问题,明确了本文的研究方向,并对论文的组织结构进行了说明。第2章是需求分析。从业务需求描述,采用流程图和用例图描绘了系统的功能需求

21、,包括指标管理需求分析、计划管理需求分析、支付管理需求分析、银行管理需求分析、公务卡管理需求分析、工资统发需求分析、数据报表需求分析和系统管理需求分析等。第3章是系统设计。详细的介绍了系统的总体框架设计、功能架构设计图,总体功能设计、数据库设计和安全设计等。第4章是系统实现。详细介绍了系统的实现环境、主要界面设计以及关键功能模块的实现过程,给出了重要功能的实现代码。第5章是系统测试。包括系统的测试环境,功能测试用例设计、功能测试结果分析以及性能测试场景设计和性能测试结果分析,并给出了具体的测试分析图。第6章是总结与展望部分。总结了本文所开展的研究工作,给出了后期系统需要改进的地方。第2章 需求

22、分析2.1 项目需求综述2.1.1 业务现状分析随着税务信息化建设不断向深度和广度发展,征管数据的采集和覆盖围日益扩大,就实际工作来看,在综合征管软件数据采集和处理过程中,出现了部分质量低下、无效、冗余、不合法、不一致的数据,税务生产系统数据质量现状不容乐观,而对于未来税务大数据的应用来说,数据质量又是一个分析系统的生命力之源。作为目前税务涉税信息的数据质量管控还未有信息化的支撑,往往在业务人员发现了数据质量事故发生或被发现之后,由信息化人员采取人工的方式去排错、去清理。目前这种基于事后,人工管控的数据质量治理手段基于以下流程展开：目前基于上述流程的人工数据质量管控有以下不足：1. 所有数据质

23、量的问题发现只能靠事后,实际工作中业务人员被动的发现,无法提前治理,导致质量事故的发生。2. 数据质量问题即使分析到数据异常规则,由于无法获知数据异常的生产来源,数据质量还会随着生产数据的产生而产生,无法从根本解决数据质量管控。3. 整个质量管控的过程成果维护起来费时费力,存在大量的返工,成本加高。4. 基于人工的数据质量管控成果信息无法归集,也无法进行成果分析和宏观的预警,无法为辅助决策提供2.1.2 业务流程分析面对目前人工执行数据质量管控的弊端,为解决目前税务局数据仓库的数据质量管控,依赖信息化系统建设,降低质量管控的难度,在降低成本的同时,增强数据分析的准确性。原则上,可以将数据质量按

24、照业务约束和技术约束来区分,例如行业认定和经营围不符合的异常数据,直接影响群体分析的准确性,所以对于这种限制于业务影响的,称之为业务约束导致的数据质量问题。对于重复记录、字符类型不符、长度不符的,编码规不符的,直接受数据库技术约束,称之为技术约束数据质量问题。受技术约束的数据质量问题,一般有估计的解决规则,发现异常可以按照重复的规则处理。受业务约束的数据质量问题,一般需要人工的治理,系统需要能自动识别和任务推送即可。将传统人工数据质量管控和信息化相结合的思路,就需要梳理出利用信息化分析的整个基于数据仓库的数据质量管控系统业务流程,目前结合传统业务,规划整个业务系统的流程如下：如上图流程,同过引

25、入信息化数据质量管控流程后,和现状业务相比,数据质量管控具有以下优点：1. 实现了数据质量规则的维护,成果会有数据保留,利于成果复用和规则完善。2. 增加了周期性的自动化扫描分析,降低人工重复查找数据质量难度和时间,节省了人力和成本。3. 增加了自动清理环节,对于分析出来的数据质量问题,尤其针对生产数据无法从源头解决的数据质量问题,一旦有确定的清理规则,可以结合周期扫描监控来及时自动化进行数据异常数据清理。4. 系统考虑到有些由于业务操作引起数据质量问题,需要具体业务人员根据实际具体治理的,则系统提供人工统筹流程,及时提醒提示治理。5. 在系统流程实现数据质量管控的基础上,进行各个环节的成果进

26、行分析,含跟踪管理和效应分析。6. 随着数据质量管控成果知识的积累,可以依赖成果数据进行宏观预警,对高发的数据质量问题或高发的群体,自动化分析,提供预警信息。2.1.3 系统角色分析按照系统业务流程分析,系统流程可分为制定数据质量模型、管控方案、扫描分析、任务统筹、质量治理、成果分析、监测预警等主要环节。扫描监控为系统后台功能,在系统流程上可以和管控方案合并为分析监控环节。按照这样的分析可以将系统共分为：质量模型、分析监控、任务统筹、质量治理、成果分析、监测预警核心业务模块。考虑该系统需要单独部署需要单独的系统管理模块。所以按照系统业务模块,划分系统角色如下：角色职责对象用户用户特点质量模型维

27、护角色维护数据质量模型信息中心技术人员熟悉数据库,且清楚数据结构和数据质量规则分析监控管理角色制定方案,分析结果监控信息中心技术人员对数据库了解,根据分析结果来调整质量模型任务统筹角色任务分配、任务下发各级信息中心领导人员清楚数据质量的清理由哪些人员来治理。质量治理角色对数据质量进行清理和数据清洗。所有税务人员进行业务数据修改成果分析角色过程跟踪和效应分析。主要各级领导人员能根据分析成果安排工作重心和治理方向分析预警角色通过预警值测算、正态分布算法、业务关联性等人工智能算法来识别潜在的数据质量风险。主要是高级别的技术人员和业务人员。有统计学背景,能有效的识别可能潜在的数据质量。系统管理角色对系

28、统用户、权限维护和日志监控系统运维人员通过对系统日志分析后,提出系统的优化和安全保障。图2-1： 图2.2 业务需求功能需求,要展开描述 功能需求的用例图、业务流程图、2.2.1 质量模型需求质量模型是将数据质量从业务转化成技术实现的基础,是将平时业务人员能看懂的数据质量业务规则通过质量模型的维护,转化到具体数据表上的逻辑规则定义。质量模型业务上的规划可分为四层设计思路,分别为数据层、对接层、逻辑层、规则层,分别通过指标元、指标和模型来维护出数据质量模型。应实现数据质量规则管理,在标准的数据质量规之上,通过数据质量审计和数据一致性比对来对数据质量进行检查,发现数据出现差错的环节。质量模型就是将

29、示意图如下：2.2.2 分析监控需求分析监控主要是将维护的质量模型通过设定分析方案、分析规则、扫描监控、数据质量信息、审核,确定通过定义周期实现执行风险模型自动扫描,最总成果为数据质量信息。分析方案可以维护自动治理规则或者选择人工质量,需要有自动的监听执行功能和高效能的分析引擎。分析监控的主要流程图如下：2.2.3 任务统筹需求任务统筹实现对审核通过的数据质量信息,进行任务统筹下发,主要存在多任务的合并和逐级下发功能。处理好任务统筹,就需要对市、区县、分局三级的用户人员功能进行操作,任务统筹可以分为主要以下环节：任务定义、任务下发、任务接收、任务合并、任务分配,通过分析可以树立出目前任务统筹的

30、一个整体流程如下：2.2.4 质量治理需求质量治理是最后管控过程的最后一道环节,主要操作对象是科所级的用户操作。质量治理在方式上要提供给用户任务办理和处置的页面,同时要有对处置结果的检测功能,确保治理后的效果。同时考虑业务上的需求,该模块还需要具有审核流程和办结等处理。所以梳理的质量治理需求流程图如下：2.2.5 成果分析需求1. 过程跟踪主要实现质量管控各个环节的成果进行统计跟踪,包括模型体系的指标元、指标、模型的建立数量；分析监控的方案、扫描分析、数据质量数据等；任务制发、流转、超限的过程跟踪；治理的进度和成果进行跟踪。2.效应分析主要是对治理前的数据质量问题和治理后数据质量问题进行宏观比

31、对,通过比对算法,对不同业务指标的计算准确性等从治理前到治理后对比,对治理前后的数据质量问题遗漏情况进行比对效应分析。通过这些分析,验证业务系统完整性,不断对质量模型进行优化。2.2.6 分析预警需求数据质量管控系统处理结果的积累上,可将数据质量管控结果作为知识积累,一方面对大量的质量数据进行分析,找出问题突出的数据质量问题和来源,有方向有侧重点的在某些行业某些区域加大数据质量管控,进行宏观的辅助决策。其次,利用整个质量管控知识库,可以根据业务数据依赖规则、数理统计、二八原理、人工智能算法等进行潜在的数据质量问题预警,提高数据质量管控的持续深入发展。核心的业务可以从分析和预警两个方面考虑：1.

32、 数据质量管控结果分析的分时间、税务机关、分质量模型、分行业等维度进行宏观分析,找出问题突发区域,进行辅助决策。2. 潜在数据质量问题的预警,依赖进行预警值测算和人工智能算法等方式进行分析,进行潜在关联的数据质量问题预警。2.2.7 系统管理需求 系统管理主要是确保系统有独立的权限控制系统和运维监控功能,主要分为权限管理和日志管理两方面,对系统安全和优化提供监控数据。1. 用户、岗位、角色管理,进行系统用户密码、身份的维护；2. 日志管理,监控系统登录日志、菜单访问日志、系统报错日志、流量监控日志的查询监控。2.3 功能需求非功能性需求。这节可以简写一点本章节采用UML建模中的用例建模来分析业

33、务需求中的需要包含的系统功能需求分析。参照系统角色分析,系统中的用户可按照角色对应分别为：质量模型维护和分析监控管理工作交由各级信息中心技术人员操作；任务统筹环节,由各级机关设置专门的数据质量管控专员负责各级任务接收流转；质量治理主要有各业务处室的业务操作人员执行；成果分析用户和分析预警用户主要提供给各层级机关局领导使用,进行宏观辅助决策工作使用；设定单独的专人做系统管理员。所以该系统的所有用户为：技术人员、管控专员、业务操作人员、局领导和系统管理员。以下是对系统流程中核心功能模块的功能需求分析,如下图系统整体用例图。2.3.1 模型体系管理质量模型体系在功能上是要将业务上的数据质量规则和要求

34、,通过系统功能进行实现定义出来,分别建立功能点来实现对接层、逻辑层和规则层的功能,所以该模块在功能上可以分为指标元管理、指标管理、模型管理三个功能来实现。2.3.1.1指标元维护指标元维护在功能上主要将数据层到应用层的对接,是将来源数据表的字段定义成可视化的业务名词,是对底层数据库到业务层的名词对照关系维护,指标元维护的主要功能有：指标元新增、指标元修改、指标元移除、指标元导出、批量新增和指标元检测等主要用例,如下图所示：表2-1指标元维护用例表用例编号Fun01用例名称指标元维护活动者技术人员优先级高描述实现将数据库表单字段,通过功能维护成为一个可以供指标和模型使用的指标元。输入输入指标元代

35、码、名称、来源表名、来源字段等。输出指标元前置条件数据连接已经准备到位,可以准确检索表名和表字段。基本流程1、 输入指标元代码、指标元名称、来源表名、来源字段名等；2、 点击保存按钮；3、 校验输入的名称长度；4、 校验不能为空项的输入；5、 检验表来源是否正确；6、检验表字段是否正确；7、 保存成功。异常流程1、 检测定义的数据库表不存在2、 检测定义的数据表字段不存在3、指标元代码重复。后置条件提示指标元保存成功。2.3.1.2指标维护指标维护功能对照业务需求质量模型的逻辑层维护功能,是将业务指标的加工规则公式和部分数据函数基于指标元定义出来。指标维护的主要功能有：指标维护、指标修改、指标

36、移除、指标导出、批量维护和指标检测等主要用例,如下图所示：表2-2 指标维护用例表用例编号Fun02用例名称指标维护活动者技术人员优先级高描述指标维护是定义出对指标元进行数理运算加减乘除后形成具体可以支撑数据质量计算的指标。输入输入指标目录、指标代码、名称、公式等。输出指标前置条件公式中所需指标元已经定义且检测通过。基本流程1、 输入指标代码、指标名称、指标公式、指标目录等；2、 点击保存按钮；3、 校验输入的名称长度；4、 校验不能为空项的输入；5、 检验表来源是否正确；6、 检验公式是否正确；7、 保存成功。异常流程1、指标公式不符合四则运算2、 指标代码重复3、指标元未找到。后置条件提示

37、指标保存成功。2.3.1.3模型维护模型维护功能对照业务需求质量模型的规则层维护功能,基于指标,定义出来数据质量业务判断过滤的逻辑规则。模型维护的主要功能有：模型维护、模型修改、模型移除、模型检查等主要用例,如下图所示：表2-3 模型维护用例表用例编号Fun03用例名称模型维护活动者技术人员优先级高描述模型维护是将多指标进行逻辑组合,定义出数据质量在业务上的逻辑过滤规则输入输入模型目录、模型代码、模型名称、逻辑公式等。输出模型前置条件公式中所需指标已经定义且检测通过。基本流程1、 输入模型代码、模型名称、模型逻辑、模型目录等；2、 点击保存按钮；3、 校验输入的名称长度；4、 校验不能为空项的

38、输入；5、 检验指标来源是否正确；6、 检验逻辑公式是否正确；7、 保存成功。异常流程1、 逻辑过滤规则无效2、 模型代码重复3、指标不存在。后置条件提示模型保存成功。2.3.2 分析监控管理2.3.2.1管控方案管理监控方案管理是设置出数据质量监控的数据围和执行规则,包括所使用的质量模型、分析期间、是否周期扫描、行业、税务机关、清理规则等。主要功能用例如下：表2-4监控方案维护用例表用例编号Fun04用例名称监控方案维护活动者技术人员优先级高描述监控方案维护是具体执行数据质量监控分析的规则维护功能输入方案名称、质量模型、所属期间、税务机关、行业、分析周期、清理规则、提示信息输出监控方案前置条

39、件公式中所需质量模型已经定义且检测通过。基本流程1、 输入方案名称；2、 选择定义好的质量模型3、 选择监控围：所属期间、税务机关、行业4、 执行策略维护：计划开始时间、执行周期5、 清理规则：人工清理、自动清理含自动清理规则6、 点击保存按钮；7、 校验输入的名称长度；8、 检验模型来源是否正确；9、 检验清理规则是否正确；10、 保存成功。异常流程1、 自动清理规则错误2、 所属周期选择跨年后置条件提示方案保存成功,启动扫描监控。2.3.2.1扫描监控管理扫描监控主要是按照维护的质量模型规则和方案规则进行自动化的监控分析,包括触发开始时间、结束时间、异常信息、结果信息等。扫描监控功能上需要

40、实现一个高能效的分析引擎来保障自动调度和智能算法解析扫描,具体功能如下：表2-4扫描监控维护用例表用例编号Fun04用例名称扫描监控活动者技术人员优先级高描述监控方案执行的情况,包括方案名称、开始时间、结束时间、分析状态、分析结果等。输入方案名称、开始时间、分析状态输出数据质量问题清单前置条件方案设定的计划开始时间满足。基本流程1、判断当前时间是否大于方案设定的计划开始时间；2、 开始执行扫描；3、 扫描执行完成,反馈结束时间、状态和结果；4、 对扫描异常错误的修改方案和模型后,发起重新分析；5、 确认数据质量问题清单；6、 提交审核；7、 审核通过。异常流程1、 扫描过程出现异常错误。2、

41、自动清理规则执行失效。后置条件产生数据质量问题清单,推送给任务统筹环节。2.3.3 任务统筹管理任务统筹管理功能是实现了将数据质量问题清单通过任务流转方式,最终确定治理人员和质量方式,确保管控流程闭环。主要功能实现省、市、县区、科所人员间的任务流转,实现数据治理任务流转到具体的处置人员。主要的功能用例如下：表2-4任务统筹维护用例表用例编号Fun04用例名称任务统筹活动者管控专员优先级高描述进行任务的定义、下发、合并、接收、回退、分配等。输入数据质量问题清单输出数据治理待办任务前置条件数据质量问题清单审核通过。基本流程1、 接收数据质量问题清单；2、 按照问题清单定义发起任务；3、 下级单位接

42、收任务,可以执行下发或回退；4、 科所局领导人员对任务进行分配；5、 确定治理方式和治理人员。异常流程1、 下发的人员不存在。2、 问题清单无法确定治理方式。后置条件产生数据质量问题治理的人员和方式,推送数据治理环节。2.3.4 数据质量治理数据质量治理主要是在确定人员和确定方式后,对数据质量问题进行清理,清理后进行下规则检测,确保数据清理的正确性。主要功能包括异常数据清理和规则检验、提交审核、办结处理。异常数据清洗、清理、验证。表2-4数据质量治理用例表用例编号Fun04用例名称数据质量治理活动者业务操作人员优先级高描述对数据质量清单问题进行修改并检测结果正确性。输入待办任务+数据质量问题清

43、单输出数据质量清理成果清单前置条件收到数据质量治理待办任务。基本流程1、 接收待办任务；2、 接收异常数据清单；3、 根据业务规则或数据规则进行清理或去重处置；4、 对治理后问题进行检测,确保问题不存在；5、 提交审核；6、 审核通过。异常流程1、 问题不存在。2、 有新的异常产生,检测无法通过。后置条件管控流程结束。2.3.5 管控成果分析在系统实现数据质量管控的流程环节基础上,对各个环节的过程成果和过程情况进行分析和跟踪,含跟踪管理和效应分析,主要功能用例如下：表2-4管控成果分析用例表用例编号Fun04用例名称管控成果分析活动者局领导优先级高描述对任务管控流程过程跟踪和对管控前后的效应分

44、析。输入数据质量管控结果数据库输出数据过程跟踪和效应分析统计表单和图形化前置条件数据质量管控结果数据库。基本流程1、 查询统计模型体系的建立情况,包括指标元、指标、模型的建立数量；2、 查询统计分析监控的成果情况,包括方案建立数量、执行成功数量、异常数据清单量；3、 查询统计任务统筹的任务制发、任务下发、任务办理、任务退回、任务分配数据量情况；4、 查询统计数据质量治理的情况,包括办结数量、逾期数量、过期数量等；5、 对同样的数据质量问题分月份查询进行比对效应分析；6、 对管控考核KPI指标进行分月比对的效应分析；异常流程1、 无。后置条件无。2.3.6 分析预警分析预警主要包括两部分功能,包

45、括宏观分析和潜在数据质量问题预警,提供给管理者辅助决策信息。宏观分析包括分税务机关、分行业、分质量模型等多维度的成果查询统计分析。数据质量预警主要通过预警算法维护、预警值测算和监控预警。具体的分析预警用例如下：分税种、分行业、分月份、分事项等；表2-4 分析预警用例表用例编号Fun04用例名称分析预警活动者局领导优先级高描述对数据质量问题进行宏观分析和潜在质量问题预警。输入数据质量管控结果数据库输出宏观分析查询结果和预警信息前置条件数据质量管控结果数据库。基本流程1、 分税务机关、分行业、分质量模型进行统计分布情况；2、 预警流程：预警算法维护、预警指标维护、预警值测算、监控预警；3、 预警算

46、法可以根据正态分布、二八原理和智能算法等,对存在质量问题超出上下限的问题进行预警；4、 对连续五天发现数据质量清单超1000条的模型进行预警；5、 对问题较多模块,按照业务的相关机进行预警。异常流程1、 无。后置条件无。2.3.7 系统管理系统管理主要功能为权限管理和日志管理两个模块容,权限管理功能包括用户管理、角色管理、岗位管理,日志管理主要是用户登录情况日志监控、菜单访问日志、系统报错日志、流量监控日志的日志监控功能。具体用例如下：表2-4 系统管理用例表用例编号Fun04用例名称权限管理活动者系统管理员优先级高描述对登录系统的用户新增和授权管理。输入用户代码、用户、用户密码、用户机关输出

47、可以登录系统的用户前置条件有维护好的岗位和角色基本流程1、 新增用户,维护信息包括：用户代码、用户、用户密码；2、 维护用户所属机关和权限机关；3、 为用户分配角色；4、 为用户分配岗位；5、 用户登录初次登录需要修改密码。异常流程1、 无岗位不能登录系统。2、 无权限机关不能登录系统3、 密码错误不能登录后置条件无。2.4 非功能需求非功能性需求。这节可以简写一点2.4.1 性能需求数据质量管控系统用户对象为所有部税务人员,全局税务人员6000名,其中主要的用户群体为信息中心负责数据运维人员使用,预计全局使用用户为1000名。按照目前的规模评估用户并峰值在100左右。系统登录性能要求为平均登

48、录响应时长不能超过5s,最长不能超过10s。系统核心是对大数据的质量监控,核心的性能问题会集中在数据统计和模型分析引擎的执行性能,既包括分析引擎对服务器的资源占用,分析过程对数据库的资源占用。性能过程需对应用服务器和数据库服务均进行性能监控和优化,服务器的CPU占用不能高于60%,存占用不超过70%。其他具体系统模块的性能要求如下：查询类业务性能要求：业务分类名称业务特征性能要求备注表证单书实现业务表证单书采集、查询等功能2S清册查询单表查2S简单多表关联查询3-5S复杂多表关联查询6-10S统计报表单表统计2S简单多表关联统计3-5S复杂多表关联统计6-10S特殊查询通过明细数据进行即时汇总

49、统计、且实时性要求比较高的查询统计。15S。超过15s项目组提交审批分析型业务性能要求：业务分类名称业务特征性能要求备注简单分析模型分析模型包含分析指标不超过5个10万级明细记录1分钟无一般分析模型分析模型包含分析指标不超过10个100万级明细记录5分钟无特大分析模型分析模型包含分析指标超过10个1000万级-1亿条以上明细记录10分钟-60分钟无单户特殊模型分析模型指标不超过10个,但单事实表可能有亿条以上数据如凭证、发票等20-40分钟可采用预处理模式2.4.2 安全性需求系统接入安全：1、渠道安全：应用系统对所有的接入渠道进行渠道安全校验,只有被许可的接入渠道才能接入应用系统。2、身份认

50、证：应用系统对所有的接入渠道需要通过口令认证方式进行身份认证,只有被许可的接入渠道及提供正确的口令才能使用应用系统提供的服务。3、权限控制：应用系统对所有的接入交易请求根据渠道进行权限控制,只有被许可的渠道接入及被允许的交易请求才能正常使用应用系统提供的服务。系统数据安全：1、传输安全：关键数据在传输过程中,必须加密传输,以保证数据的传输安全性。2、存储安全：根据国家税务局等级保护三级要求,应用系统必须保证数据的存储安全。因此,在税务局部网络环境下,必须将与业务相关的数据保存在税务局网区域核心区域。2.4.3 可扩展性需求系统应能适应税务数据应用需求复杂多变的要求,考虑未来 3-5 年的可扩展

51、性,采用构件化设计思想,系统框架与业务逻辑分离,具备开放的可扩展体系结构,支持在线升级和扩展,支持多用户和并行访问。系统的设计应确保在用户系统保存已有和未来至少五年的共十年以上最明细的业务数据。进入数据仓库的数据应与生产系统中的数据保持一致。经过数据清洗、装载、查询、展现后为用户提供准确的数据。2.4.4 其他技术需求建立统一的数据模型标准。技术框架采用J2EE架构,JAVA语言为主要开发语言,基于B/S和关系型数据库方式实现。具体需求如下：系统后台采用WINDOWS SERVER、UNIX 等平台、WEBLOGIC等应用服务和 ORACLE大型数据库。第3章 系统设计33.1 应用体系设计根

52、据总体设计,操作型业务与分析型业务需要进行分离设计。本系统的模块可划分如下：业务类型业务模块操作型业务模型体系管理任务统筹管理数据质量治理分析型业务分析检控管理管控结果分析3.1.1操作型业务操作型业务设计以生命周期管理为核心,以工作流的驱动方式执行全流程的闭环控制管理。本子系统的操作型业务有模型体系管理告、任务统筹管理、数据质量治理等业务。下面重点阐述管控生命周期管理,其它模块的设计重点为数据模型设计,将在数据体系结构中展开。1. 数据质量管控的生命周期管理 如下图所示：说明：l 生成数据质量扫描得到的扫描疑点的明细信息,进入数据信息库。l 处理数据扫描疑点明细信息,需要进入疑点风险评价环节

53、,该环节是疑点信息量化的主要步骤,将通过排序等手段,生成疑点数据等级等信息。l 消除数据疑点信息在应对完毕之后,通过应对系统的反馈,消除该数据疑点信息。2. 数据质量管理闭环控制数据质量管控管理是一个闭环操作,围绕数据疑点管理战略目标实施,通过疑点数据识别、分析、评价、应对、管理全程监控及结果评估构成闭环,同时通过不断的监控、分析报告对整个管理过程进行持续改进。闭环需要较为完备的流程控制,以上描述的生命周期管理,将以工作流的驱动方式进行管理,工作流程图如下所示：说明：序号节点状态1数据质量风险特征库维护风险识别,输入1风险方案2特殊数据信息采集风险识别,输入2可选,作为风险评价的输入3数据质量

54、风险扫描方案风险分析,处理1作为风险扫描的输入4数据质量风险扫描数据质量扫描,处理35数据质量风险评价数据质量评价,处理46数据风险疑点应对数据疑点应对,处理57数据风险疑点应对反馈结束综合分析数据质量管控的主要功能模块,以及数据质量管控与其他子系统的关联使用,得到以下体系结构图：数据质量管控体系结构图说明：1. 总体技术架构公司的技术架构,包含前端、web、框架、通信各个层面解决手段。2. 指标管理平台数据质量管控基于指标管理平台设计,指标管理平台提供丰富的支撑功能。3. 核心服务系统的核心服务,如组件管理,运维管理等。4. 业务逻辑层业务逻辑的封装,隔离底层与界面层的交互。5. Web应用

55、功能1) 界面层数据质量管控主要分为7个模块：模块说明模型体系风险识别是整个风险分析工作的基础,主要的成果有三个：风险特征指标、风险特征模型、特殊风险信息。分析监考风险分析是产生风险信息的关键步骤,产生的风险明细数据,供风险评价阶段使用。该模块的主要环节为：风险扫描方案、风险扫描、执行监控以及分析结果的查询。任务统筹数据来源：风险信息库中,除了任务类的风险信息,进入风险评价环节。目的：得到纳税人的风险总分值,并评定等级。手段：依据评价初始化参数,记忆风险总分值计算算法,评定等级算法,展开排序工作,并可以人工调整。数据治理进行任务批次的定义,经过审批和下发后流转到应对机关。成果分析应对机关对任务

56、进行分配后,进行实际的处置后,再进行任务反馈。分析预警提供数据质量管控的监控查询。系统管理对数据质量管控系统运行成效的监控和评价。6. 接口数据质量管控的接口层,与外部系统的接口都在此层面规划。3.1.2分析型业务数据质量管控的分析型业务主要有指标预警值测算和风险扫描等,这两个业务都是依赖指标管理平台,如下图所示：指标预警值测算是数据扫描的一个必要输入,在扫描过程中,可能会使用到指标的预警信息如均值、上下限等,这些都是需要事先预处理的,指标管理平台提供相关的指标测算服务。扫描是对扫描方案的执行过程,在分解了扫描方案之后,主要的工作就是调用指标管理平台的分析引擎服务,执行相关的操作,并保存结果。

57、3.2 架构设计3.2.1技术架构本项目采用J2EE相关的架构进行开发,技术架构图如下：架构说明：1. 整个架构主要由客户层、中间层web层、架构层、E层、资源层组成。2. 客户层：系统最终用户的使用界面和设备。一般为基于浏览器的瘦客户端,比如IE等；本项目中使用了SUI来实现展现效果。3. 中间层：用户和系统之间的交互管理,提供用户层的展现逻辑和对资源层的访问接口。该层主要采用Front Controller, Request Processor, Command, View Dispatcher,DAO、工厂等设计模式来实现。本项目在WEB层使用Webfaster,在架构层使用SOA。4.

58、 资源层EIS：各种信息系统资源,在本系统中主要用到了：RDBMS,以及文件数据容器主要是在分析引擎中使用。3.2.2体系架构界面管理模块的执行过程如下图所示：说明：1. 用户通过操作界面与系统进行交互。2. 用户操作的数据经过展现层、接口层、核心层,最终存储到数据层中。3. 展现层包括了传统架构分层中的界面层、web层、架构层、业务逻辑层的一部分。4. 接口层、业务核心层是对传统业务逻辑层的进一步细化,业务核心层包含了传统业务逻辑层的大部分容；部分功能遵循此结构。应用执行体系将设计期和运行期分离设计,将部分功能充分松耦合,达到灵活性、可扩展性和复用性,如下图所示：说明：扫描方案执行器接收到扫

59、描方案实体对象,将对象解析后调用指标管理平台提供的算法和子系统部处理逻辑,完成扫描,输出扫描结果信息。在设计期,系统只需要生成样扫描方案等容,将这些容存于数据库即可。在运行期,通过手动触发或者系统自动任务监听,读取并解析设计期的成果,生成相关的执行实例,调用分析引擎等工具,执行得到结果,写入执行结果相关数据库表。方案是数据质量管控的关键数据对象,是扫描的基础,它需要满足风扫描这一动态执行功能的业务和技术两方面的要求,这个要求如果再做一个逻辑抽象,可以很直观地将方案划分为两个执行部分：方案的执行实体和方案执行参数。除此之外,方案还要能提交到知识库与大家分享,方案可以方便展现出来。综上分析,这个关键数据对象的划分如下图所示：执行实体指明的是扫描执行的具体业务对象、风险分析算法等容,执行参数则是用于支撑动态执行所必须的周期频率、执行时间等参数。更具体的设计容见关键设计章节。风险方案执行器在接收到扫描方案实体对像后,先进行对象的检测,以确定对象是否适应当前的执行环境。检测通过之后,执行对象的解析,产生可以计算的实体对象,如指标信息,计分规则信息等。然后依据对象的类别调用不同的执行器实现类执行运算,运算过程中根据需要调用指标管理平台提供的算法,最终完成运算结果的输出。具体实现流程如下图所示：说明：方案如果想正确执行,