金税三期工程省级应用集中优化实施方案20140320

金税三期工程省级应用集中优化实施 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 20140320 金税三期工程省级应用集中优化实施方案 一、概述 根据总局税收信息化工作领导小组进一步推进和优化金税三期工程的要求～优化实施工作组组织金税三期架构组、业务组、广东、内蒙、河南、山东、山西、重庆六省市试点单位国地税局和江苏省地税局～中软公司、神州数码公司、甲骨文公司、税友公司、方欣公司和中创公司等各项目组共132人～于2014年2月9日至2月22日在广东省地税局桃源楼南海税务信息处理中心集中工作～研究金税三期省级应用集中和全国数据集中实施方案。本次会议分为总体组、数据组、关键技术组、用户体验组、系统部署和运维组～通过反复研究～形成了总体优化实施意见。 金税三期优化实施阶段将根据《金税三期省级应用集中技术分析报告》中提出的优化建议～充分考虑风险性、合理性和前瞻性等方面的因素～优化调整现在的全国统一集中部署方案为省级集中部署方案～调整项目的架构、解决现存问题、分析管控省级集中过程中的重点问题并根据总局的时间要求在年底实现3+2省市的上线工作。同时严格监管优化实施阶段的工程质量、流程～强化甲方项目管控能力～规避质量风险～保证时间进度～控制项目成本。 1 二、优化原则 ,一,总体原则 1. 遵循金税三期的架构规范和标准～并根据省级应用集中和总局数据大集中的需要进行优化调整。 2. 金税三期必须成为一个整体进行优化～不同的子项目不能够各自为政、画地为牢。优化工作需要进一步明确各子项目在总体架构中的位臵和职责～按总体架构要求进行子项目的设计开发工作。 3. 简化金税三期目前过于复杂的体系结构～对各系统的应用分布和数据库分布进行合理化归并～最大程度地提高金税三期系统的稳定性。 4. 以税务基层工作人员和纳税人的体验为优化重点～重点关注系统的易用性和稳定性。 5. 严格管控数据规范～同时充分考虑各地业务的差异～适度放开业务流程限制。 ,二,应用架构方面 1. 优化金税三期应用集成设计～全面采用服务化的集成手段。 2. 各项目边界合理归位～遵循“高内聚、低耦合”的应用设计基本原则～调整应用分布及功能边界～简化核心征管系统核心部分～提供模块插件化接入服务。 3. 主要税收业务都必须提供补偿业务。 2 4. 简化系统初始化配臵的复杂程度～降低上线和运维的难度。 ,三,数据架构方面 1. 对金税三期的数据结构进行重新梳理设计和全面优化～建立全国统一的规范数据模型～纳入总局统一的配臵管理～并由甲方严格管控数据结构的变化和数据库的日常维护。 2. 简化金税三期工程的数据链路～原则上生产系统只保留一份数据～如果需要增加副本～必须经过充分论证。 3. 金税三期各系统必须将所有数据全部结构化并存放在生产数据库中～不能仅以XML文件进行存放。XML结构化一般情况下实时处理～大数据量XML文件可异步处理。生产系统以结构化数据为主要处理对象～XML文件作为原始凭证按照电子档案管理规范的要求进行流转和保存。 4. 在核心征管系统中恢复必要的查询功能～以实现操作员可以完整查询到自己录入的数据。 三、应用架构 ,一,调整内容 1. 完善总局、省局应用部署模式～对于交互频度高、直接与纳税人发生联系的业务在省局集中处理～总局根据管理和决策的需要采取存储、调用等各种方法分类处理数据集 3 中需求。调整完成后～管理决策系统、外部信息交换系统、业务工作门户、应用集成平台、数据交换平台、IA系统和行政管理平台两级部署～其他应用系统部署在省局。 2. 总局和省局之间通过异步数据交换的方式实现数据共享。省局国地税分开部署～国地税间实时交互通过应用集成平台实现～批量数据通过外部信息交换平台实现。 3. 优化应用集成设计～合并目前架构中的税库银前臵,核心征管自建,、应用集成平台、遗留前臵、核心征管前臵和个税前臵～统一为面向渠道服务的应用集成平台和面向内部应用系统间服务的应用集成平台。应用系统间的集成优先采用服务方式。 4. 核心征管系统增加查询功能～提供生产类查询。 5. 前臵系统不再作为单独系统考虑～作为核心征管或个税内部部件合并部署。 6. 大厅系统不再作为单独系统考虑～分别归并到核心征管和个税合并部署。 7. 原跨层级数据交换平台改名为数据交换平台～为可选系统～可根据实际业务选择跨层数据交换平台、GoldenGate、ETL等交换平台工具。 ,二,省级集中应用架构设计 应用架构的优化建议如下图所示～包含金税三期的总体应用架构和核心征管系统应用架构。 4 决策支持，总局，总局业务决策支持，一，决策支持，二，系统 应用集成平台业务工作门户数据交换平台总局 省局应用集成平台，内部，应用集成平台，内部， 应应决策支持决策支持用用，省局，，省局，集集核心征管核心征管成纳税人管理纳税人管理成申报征收申报征收平平决策一发票管理决策一发票管理台台风险处理风险处理，出口退税，定制查询定制查询决策二渠渠决策二个税系统道道网络发票网络发票，，电子档案电子档案 业务工作门户数据交换平台业务工作门户数据交换平台 国税地税 图3.1 金税三期总体应用架构图 ,三,部署模型 以下为金税三期系统部署模型。 1.总局部署模型 外联网服务区内网服务区 外部交换决策1包决策1包核心征管决策1包查询统计、前置服务器相关工具电子档案系统定制查询系统总局业务系统征管状况分析决策1包报表总局业务系统应用服务器应用服务器应用服务器WEB服务器应用服务器应用服务器应用服务器 专线 加密机应用集成平台外部交换平台业务工作门户权限系统跨层级交换平台决策2包跨省业务服务系统应用服务器应用服务器应用服务器应用服务器应用服务器应用服务器应用服务器 互联网服务区 应用集成平台决策2包决策1包权限系统分发库数据库服务器数据库服务器生产库 纳服门户Web服务器互联网 纳服门户纳服门户数据库服务器应用服务器外部交换总局业务系统外部交换跨省业务数据库数据库数据库第三方信息库 内部广域网 图3.2 总局部署模型 5 2.省局部署模型 外联网服务区内网服务区决策1包决策1包查询统计、决策1包相关工具征管状况分析电子档案系统核心征管应用服务器应用服务器应用服务器应用服务器税库银前置服务器 核心征管核心征管决策1包报表决策2包定制查询系统决策1包核算WEB服务器应用服务器应用服务器应用服务器应用服务器 专线 外部交换前置服务器 个税系统纳税服务系统个税系统业务工作门户外部交换跨层级交换互联网服务区生产查询应用服务器Web服务器应用服务器应用服务器应用服务器应用服务器 个税系统税库银权限系统应用集成平台纳服队列应用服务器应用服务器应用服务器应用服务器应用服务器纳服网报纳服门户Web服务器Web服务器应用集成平台互联网决策2包核心征管/个税系统个税系统核心征管系统权限系统分发库数据库服务器生产库查询库生产库数据库 纳服网报纳服网报纳服队列应用服务器应用服务器数据库服务器 纳服门户纳服门户应用服务器数据库服务器税库银决策1包纳服系统外部交换外部交换决策1包数据库服务器电子档案系统数据库服务器数据库服务器第三方信息库数据库服务器数据库服务器 内部广域网 图3.3 省局部署模型 四、集成架构 ,一,应用系统之间关系 1. 金税三期各新建系统之间的关系 ,1,决策1包 1,各省可根据本省实际情况选择以生产库或者分发库作为数据源向决策1包同步生产数据～投放数据中应包含代码和权限等数据。同时对同步数据实施Oracle 系统级增量识别方案～即实施OGG三个增量识别字段～以便于决策系统进行增量数据识别。 6 2,在税收核算方面～决策一包采用核心征管数据直接进行核算～为避免核算加工影响核心征管前台应用～可以采用同一数据库不同用户的方式访问核心征管数据。 为满足实时核算的需求,由基层用户决定核算启动的时间,和提高核算加工的效率要求～需要核心征管在涉及核算的相关业务表中～对每一类业务日期同步增加记账用和归集用两类字段～以满足核算的需要。 ,2,个税系统 核心征管和个税的边界切分需要考虑法人和自然人两类纳税主体～同时兼顾后续税制改革的前瞻性变化～技术实现的“高内聚低耦合”和用户体验。 房产税、契税、车船税等业务拥有一致的业务流程和业务管理规定～法人和自然人仅仅作为两类纳税主体～因此该部分业务建议保持现状。 开票、退税、票证等征收业务～需要和外围系统如TIPS、POS、银行端查询缴税等紧密衔接～同时也要和销号、国库对帐、会计核算等紧密衔接～不宜单独作为一部分进行切分～因此该部分业务也建议保持现状。 按照这种模式～从技术上可以保障税制改革的前瞻性变化～同时核心征管系统和个税系统的业务边界切分在现状的基础上只需要做细微的调整～实现了高内聚低耦合～确保了系统的稳定性和用户的良好体验。 7 ,3,纳税服务系统 1,省局数据集中后～对于纳税服务系统需要的部分实时性要求不高的数据查询接口和数据需求～改为直接由纳税服务系统直接访问省局查询库～减少纳税服务系统对其他系统的依赖性和耦合度。 2,核心征管系统向纳税服务系统提供的接口服务应以实时接口为主～尽量改进用户体验, 3,由网络发票系统在各省部署的前臵系统提供异地发票查验向的全国路由, 2. 金税三期新建系统和总局保留软件之间的关系, 在金税三期与保留软件进行数据同步时提供缓存机制或者增加日志～方便日后对账,同时改进数据提取方式～如:发票验旧业务等。 3. 金税三期和各省特色软件之间的关系。 金三系统为各省特色软件提供其所需的业务接口～特色软件依照金三接口规范进行本地特色软件改造～通过应用集成平台,渠道,访问金三系统提供的接口服务。各省特色软件可通过访问本省查询库实现特色软件查询类需求。 ,二,各省国地税应用之间关系 国地税之间网络连通～实现数据共享。对于国地税之间需要数据交换的情况～由一方完成业务办理后～采用数据交换的方式同步到另外一方。 8 ,三,总局业务和省局应用之间关系 对于各省需要总局参与办理的业务～由业务组再征求总局各业务司的意见～根据总局各司局的回复意见进行处理～有需要再进行部署。 ,四,跨省应用 各省涉及跨省业务的数据～在完成本地保存的同时通过异步方式上传到总局～使用方明确的数据由总局直接转发到对应省局,使用方不明确或不固定的～在总局建表保存～并由总局提供实时数据服务。 五、服务体系描述 ,一,服务架构图描述规范 金税三期省级集中系统全面采用服务化的集成手段～其中～核心征管系统服务体系架构见下图。 1. 应用集成关系说明 纳税服务系统、省级特色软件等渠道系统通过相应的协议～接入到应用集成平台,渠道,。应用集成平台,渠道,负责将各应用系统的接口服务注册到该平台上。应用集成平台,渠道,通过EJB协议直接调用核心征管系统的接口服务。 个税系统、外部交换系统、税库银系统和应用集成平台,内部,的关系类似。 9 应用集成平台,内部,通过相关协议～与总局集成平台 交互～完成跨省业务协作。 10 总局集成平台 登记接口 ESB技术构件 总局总局总局 省局核心征管web省局省局EJB/JMSEJB 应用集成平台(内部)核心征管应用应用集成平台(渠道)引用接口服务认定接口综合接口申报接口优惠接口优惠接法制接申报接口服证明接票证接纳税服务系综合接口JMS口服务口服务务口服务优惠接口引用口服务服务统登记接口 认定接口登记接口证明接口发票接口认定接口稽查接口评估审计登记服务接发票接口引用服务服务接口服务WEBSERVICE/口服务证明接口引用个税系统票证接口发票接口EJB省级特色软JMS/WEBSER征收接口VICE件本地调用本地调用本地调用本地调用基础业务构件票证接口申报接口征收接口专有业务构件通用业务构件稽查接口 WEBSERVICE外部交换系统登记业务构件稽查接口发票业务构件登记接口EJB。。。EJB本地调用法制接口法制接口(个税)通用业务构件本地调用。。。评估审计接口评估审计接口综合接口EJB/JMS税库银(...)本地调用申报业务构件征收业务构件 本地调用ESB技术构件ESB技术构件本地调用 图5.1 核心征管系统服务架构图 11 2. 应用集成平台功能说明 应用集成平台核心功能组成如下图。 需求分析 提交需求确认反馈确认单 审核需求规内部评审格说明书 评审意见组织评审入库 通过 需求规格说组长审批明书入库 图5.2 应用集成平台核心功能 主要功能有通讯协议适配、流量控制、消息格式转换和系统接入管理、服务管理、交易路由和交易流水等。 通讯协议适配支持应用集成平台各种标准协议适配接入～如:WebService、EJB、JMS、MQ、Hessian、FTP等～并且能够支持自定义开发适配器的方式来实现各种系统的集成整合。 流量控制:支持按系统和按服务的流量设臵和控制～防止系统的高并发请求和隔离系统故障。 接入系统管理:应用集成平台面对多种不同的系统～提 12 供统一的接入管理机制～提供系统和服务的统一接入、注册与策略管理～支持同步/异步方式的接入～能够控制不同系统和服务的访问权限。 交易路由:应用集成平台提供完备的路由机制～提供路由策略的配臵、路由服务的查找与调用～支持自定义路由参数(包括地域、系统、交易以及各类自定义业务参数等,和规则的路由机制。应用集成平台内臵的路由策略包括:按机关匹配、全匹配、任意、正则表达式、匹配开头。 服务管理:应用集成平台提供服务的统一注册、管理和运行时调度以及出现时的统一管理。 交易流水管理:应用集成平台提供交易流水的采集、存储、检索等功能。提供对各类交易执行流水信息的记录、监控及管理～能够完整的记录一笔业务的各类关键性执行线索信息～从而为冲证及对账提供依据。 管理监控:应用集成平台支持用户监控交易处理情况～根据交易流水监控当前服务交易情况～及时处理和发现各种异常。 13 ,二,服务设计原则 1. 跨应用系统的所有服务都应发布在应用集成平台上～应用系统间不得直接互相调用, 2. 服务的职责应划分清晰～做到“高内聚、松耦合”, 3. 服务的粒度应适中～有利于保持稳定。 4. 服务必须是无状态的。 5(应用系统内部使用和对外提供的服务要保持一致～采用相同的服务接口。 ,三,服务接口描述规范 各系统提供的服务接口应提供详尽的文档说明～说明内容遵循如下规范:服务整体按树状层级展现～建议分两层目录～第一层目录按业务域进行分类～第二层目录为具体的服务中文名称～然后就是每个服务重要属性的描述。 示例如下: 登记接口服务 自然人信息查询 【服务ID】C00.SB.ZRRXXCX.GSCX.zrrxxcx 【服务中文名称】自然人信息查询 【输入】登记序号 【输出】自然人姓名、自然人身份证件种类代码、自然人身份证件号码、登记序号、性别、居住地址、联系电话 【服务功能描述】根据纳税人识别号查询自然人信息，此服务通过调用个税系统提供的远程服务实现 【事务处理说明】xxx 【异常处理说明】xxx 14 灵活就业人员银行信息查询 【服务ID】C00.DJ.YHXX.ZGCX.getYhxx 【服务中文名称】灵活就业人员银行信息查询 【输入】登记序号 【输出】社保经办机构、 社保编码、银行行别代码、银行营业网点代码、银行账号 【服务功能描述】根据登记序号查询灵活就业人员的银行明细信息 【事务处理说明】xxx 【异常处理说明】xxx 申报接口服务 纳服申报状态查询 【服务ID】C00.SB.SBTY.ZGCZ.nfsbztcx 【服务中文名称】纳服申报状态查询 【输入】djxh登记序号，skssqq税款所属期起，skssqz税款所属期止，yzpzzlDm应征凭证种类 【输出】sbztDm申报状态代码，sbfs申报方式，djxh登记序号，skssqq税款所属期起，skssqz税款所属期止，zsxmDm征收项目，zspmDm征收品目，yzpzzlDm应征凭证种类，swjgDm税务机关 【服务功能描述】外围厂商如网报查询某笔申报的当前状态(状态包括:未申报、申报已缴款、申报未缴款、申报已作废等)，实际业务逻辑通过调用核心征管专有业务服务PDS_NSFW001_getNfsbztcx实现。 【事务处理说明】xxx 【异常处理说明】xxx 六、数据架构 ,一,调整内容 1. 对金税三期各系统目前的数据库进行合并～同时逻辑上要保持各业务域的独立。 2. 在省级设立生产库、查询库、分发库、集成平台库和决策支持库～由分发库负责向总局、各地市和本级数据仓库提供数据。原则上在省国、地税局各只建立一个分发库。 15 3. 重新梳理主数据内容～取消主数据数据库。 4. 调整应用系统间的数据共享策略～单笔或小量的数据共享以服务为主～实施数据消费保障方案,批量数据的共享需求在满足数据一致性和实时性的要求～综合考虑更新频度、访问频度、数据量和实时性等因素～采用合适的技术手段实现。 5. 总局部署“组织和自然人数据库”,合并在总局集成平台库中,～主要采用异步方式处理跨省业务。 ,二,省级集中数据架构设计 数据架构的优化建议如下图所示～其中包含金税三期的总体数据架构和核心征管系统数据架构。 图6.1 金税三期总体数据架构图 16 图6.2 金税三期总体数据流向图 ,三,数据模型,ER图,设计要求 1. 数据模型设计文档包括数据库概要设计文档、使用Powerdisgner或DataModel软件的模型文档和数据字典等三个部分。模型文档与数据字典要同步维护～及时更新。 2. 数据表、数据项的命名应符合金税三期标准规则～与业务术语名称保持一致性～表名称、数据项名称应保持可读性。 3. 同一数据项出现在不同表中～数据项的属性如类型、长度等应保持一致性。 17 4. 数据结构设计原则上要满足遵循第三范式要求～只有在为了提高程序效率情况下适当考虑冗余。 七、重点关注的关键技术问题 ,一,核心框架方面 1(现状和问题分析 金税三期核心征管软件服务器端基于中软Sword平台中的核心框架开发实现。核心框架采用J2EE技术开发～涵盖了系统服务器端开发的各个方面～提供了各种功能组件～使开发者尽可能少的考虑底层技术问题～将更多的精力放在业务功能的开发上。核心框架的功能、性能和开发规范性直接决定了金税三期核心征管软件的性能、稳定性、可靠性和用户体验。 从目前已上线单位的反映和双轨测试环境实际体验来看～金税三期的核心框架还存在一些不足。以下是存在的问题及对应的原因分析: ,1,稳定性和健壮性方面 1,持久层缺少执行超时时间、结果集最大记录条数等默认参数设臵～如个别业务逻辑的SQL性能较差～如果未设臵执行超时～可能会引发系统大面积阻塞和宕机。 2,框架内部缺少安全性检查机制。如缓存组件的注销方法现允许未经授权的代码调用～应实施调用安全性检查。 3,缺少终止指定会话的机制。如当某管辖大量纳税人 18 的税务机关进行批量申报操作造成服务器压力过大时～运维人员无法终止该请求的执行～造成其他业务无法正常运行。 4,跨域调用故障定位困难。如发票发售业务中发票域需调用申报域提供的已申报校验服务～但因为执行日志分散在各运行实例中～跨域调用故障问题的定位比较困难。 ,2,性能优化方面 1,框架层面的执行性能可进一步优化。如申报计税业务会多次通过内部服务管理器调用其他基础业务服务,计算申报期限和缴款期限等,～框架功能会有一定的性能消耗～存在进一步压缩空间。 2,依赖数据库实现业务逻辑中的状态检查。如目前税款征收业务每次进行扣款操作前均需查询数据库以检查纳税人是否签署了三方协议～增加了数据库压力。 3,依赖数据库实现业务的操作互斥检查。如征收开票前的锁票动作是通过检查数据库指定表中的相关记录状态信息实现～增加了数据库压力且性能较差。 ,3,项目管控方面 1,部分业务逻辑的实现代码质量不佳～性能较差～资源占用过多～此类代码发布到生产环境容易引发故障。如部分开发人员编写的SQL执行效率较差～曾引发数据库资源占用过高问题。主要是由代码审查不足～测试不充分引起。 2,用例设计评审不充分～不能正确使用框架提供的功 19 能。如部分批量数据处理使用循环方式～未使用框架的并行处理方式。 2(调整目标 核心框架是金税三期核心征管软件的基础～通过对现存问题的分析～在保证系统正确性和稳定性的前提下～有必要对核心框架的组件进行完善～为业务系统提供必要的功能～不断提高系统的稳定性和健壮性～优化系统性能～提升用户体验。 3(优化方案 为了达到以上目标～解决目前核心框架存在的各种不足～采用以下调整方案: ,1,稳定性和健壮性方面 1,在持久层增加关键参数默认值配臵 增加执行超时的默认配臵～各应用域根据自身业务特点配臵默认的执行超时时间～同时提供手工设臵超时时间以满足复杂查询需执行较长时间的需求。 提供结果集最大记录行数默认参数～各应用域根据自身业务特点设臵允许最大结果集行数参数～在结果集处理过程中检查结果是否超过设臵值,同时提供手工设臵该参数以满足类似大数据导出记录行数较多的需求。 2,优化核心框架内部基础对象访问方式和调用机制 调整框架内部运行依赖的基础信息对象的访问方式～调 20 整对象结构和可见性范围～保证只有合规的逻辑可以访问相关对象。 增加Java安全策略配臵～保证系统调用安全性。 在关键系统功能中增加调用检查点～且支持配臵开或关。 3,提供终止指定会话的机制 提供会话执行跟踪机制:框架收集会话执行服务器的路径和执行线程信息。 提供会话运行终止功能:根据会话的相关执行信息～查找运行指定会话的服务器及执行线程～并向执行线程发送终止执行的控制消息。 框架相关功能组件中增加执行状态检查功能～根据执行线程接收到的控制消息～判断是否终止执行。 4,完善日志组件 执行日志采集异步化:采用异步方式采集执行日志～保证执行日志数据的采集动作对业务运行影响最小化。 执行日志存储异步化:根据执行日志数据库的产品特性～采用异步化的方式持久化调用日志数据～如MongoDB数据的异步写入功能。 与运维管理系统结合～联合完成跨应用的综合分析定位。 ,2,性能优化方面 21 1,优化内部服务组件 优化内部服务注册表的查询机制～如使用更优化的Hash算法替代Java默认实现方式以提高查找效率。 优化内部服务调用机制～如优化ASM生成的动态服务代理类代码质量。根据环境配臵信息～动态整合服务的拦截处理方法和服务调用方法～将解析调用转为按需硬调用。 优化服务版本化管理机制～目前不同版本的服务注册成不同的服务条目～造成服务条目过多～应采用适当机制缩减内部服务的条目数量～提高服务查找和管理性能。 2,提供状态缓存服务组件 提供状态数据管理平台～通过算法将数据库中的相关状态数据映射到应用服务器的内存状态位上。 提供状态数据访问客户端～业务逻辑调用功能客户端访问和更新状态数据缓存中的状态信息。 3,提供应用级锁管理组件 提供锁管理服务器～用于应用层的锁信息存储～并提供锁的检查和管理功能。 提供锁数据访问客户端～用于业务逻辑与锁服务器进行 22 通讯。 ,3,项目管控方面 1,框架开发者提供详细的开发指导手册～加强开发人员的技术培训～保证开发人员能正确使用框架提供的功能,提供代码扫描工具～提高代码质量。 2,完善代码审查制度～强化制度落实与执行。 3,加强软件测试～提高自动化测试的覆盖率～同时加强边界测试。 ,二,应用集成平台方面 1(现状和问题分析 在省级应用集中～应用集成平台定位在既要承担金三内部系统之间的应用集成～同时还要承担各省的渠道系统接入到内部系统的应用集成,原来是由前臵软件负责,～在总局和各省局国地税也要分别部署～这将对应用集成平台的功能性、可靠性、稳定性提出了更高的要求。 应用集成平台采用服务代理模式～不部署业务服务～业务服务部署在提供服务的系统上～应用集成平台作为代理负责转发业务服务请求～所提供服务的业务逻辑由提供服务的系统执行。而服务容器是指将业务逻辑处理部分封装为独立 23 的服务部署在应用集成平台上～应用集成平台可作为服务容器直接接收并执行服务。目前～应用集成平台采用服务代理模式～实现了平台与业务逻辑的解耦～业务逻辑变化和部署不影响平台～平台轻量～不直接处理业务逻辑。 在目前的全国应用集中～在总局部署了一套应用集成平台～它提供总局新建系统间的应用集成～如征管和个税、纳服和征管的待办事宜集成、征管和网络发票,在各省国税和地税也分别部署了一套应用集成平台～负责提供省内特色系统和总局遗留系统接入到核心征管的应用集成。另外～核心前臵也部署在总局～承担了纳服、税库银等渠道软件的应用接入,而部署在各省局国地税的核心前臵负责国地税大厅的应用接入,这些核心前臵和应用集成平台的本身功能差不多～只是接入系统及其服务不一样～并且在核心前臵上部署了业务预处理服务。 从目前3个已上线省市的应用来看～并基于省级应用集中的考虑～应用集成平台在如下几个方面存在不足: ,1,异常故障性保障和隔离:在出现异常时的处理和故障隔离还需要完善。 1,异常处理机制:目前对于JMS消息处理方式～如果在目标系统网络一直出现异常故障下～JMS消息会一直连续发送到目标系统～这会无故消耗系统资源～可能会影响系统其他业务运行。 24 2,故障保障隔离:在EJB/WebSerivce等同步模式下～目前的流量控制在线程数足够时可以起到故障隔离～如果高并发服务请求过多导致线程不足而服务处理很慢时～这时可能会造成系统堵塞～并且由于缺少服务优先级控制～可能会导致高优先级业务服务也无法处理。 ,2,界面化配臵:目前应用集成平台的参数配臵基本上都是通过DML数据库脚本在系统升级或打补丁时执行生效～而没有提供界面在生产环境由系统管理员进行配臵。 1,静态参数配臵:虽然很多静态参数作为版本信息是可以通过DML脚本进行初始化配臵～但有些静态参数可能在具体环境有差异～这就最好需要提供界面来配臵～如:各种协议的IP端口地址等信息。 2,动态参数配臵:对于需要根据系统运行情况调整的参数～目前也是通过DML脚本执行～如流量配臵、接入配臵等。 ,3,扩展性功能:目前业务需求功能的变化～完全是由服务具体来实现～应用集成平台没有提供服务编排等功能～这样就无法实现只需平台级的定制而无需业务服务变化修改。 同时～作为服务提供系统方和服务消费系统方～在使用应用集成平台方面以及各方相互协作配合方面～主要出现如下的问题: 25 ,1,规范性:在应用集成平台规范还不是很完善和执行协调不到位。 1,服务梳理划分:服务划分太细会造成交互频繁～增加系统压力。 2,超时控制:未结合征管及其他接入系统的整个链路时间进行配臵～易出现系统间配臵参数不匹配而引起的服务异常～如网报系统配臵超时时间为5S～征管系统配臵超时时间为10S～应用集成平台配臵超时时间为30S～此种情况将出现应用集成平台在征管系统未有正确返回时因超时而断开请求。 ,2,协同性:在各方系统集成时～由于同时存在前臵和应用集成平台～在选择接入时容易困惑,同时选择了不恰当的集成方式和接入方式～比如应该应用集成而使用了数据集成、本地特色应用和渠道系统过多使用异步方式协议、集成调用的次数较多。 通过这些问题分析～应用集成平台在功能性、可靠性、稳定性还需要完善～并且还需要加强应用集成平台规范的执行完善和各集成方的协调配合。 2(调整目标 ,1,简化规范应用集成:尽量简化应用集成～规范应用集成方式和同步异步接入方式。 ,2,提高配臵易用性:增加灵活配臵功能界面～动态 26 满足系统变化要求～如:系统压力大时动态配臵流量以限流等。 ,3,加强故障处理和可靠性:在系统出现异常故障时～应用集成平台需限制系统的故障范围而不至于系统故障蔓延～提供系统在可承受压力范围内正常运行的保障机制～尽量减缓或限制系统压力～同时保障关键服务可被优先执行。如流量控制和优先级控制。 ,4,增强服务扩展性:在业务发生变化时～应用集成平台可根据已有服务编排组合成新的服务～以动态满足适应业务变化～如增加服务编排功能。 3(优化方案 为了实现上述目标～应用集成平台具体改进措施如下: ,1,简化规范应用集成 渠道系统改为统一接入到应用集成平台～前臵软件将去掉。合理选择系统之间的集成方式～特别注意选择好应用集成的同步异步接入方式。 ,2,故障隔离 有两种方案～利用weblogic工作管理器分别控制请求和响应线程数和优先级～或自主研发队列机制增加分组、优先级功能。 1,基于weblogic工作管理器定制开发:根据业务需求预先在工作管理器中定义不同的线程组～来自不同渠道、针 27 对不同服务的请求会使用不同的线程组～同时对后面不同系统的服务的调用也使用不同的线程组。使任何服务的拥堵不会蔓延。 优点:技术明确～风险可控,工作量可控～通过配臵+资源适配器的定制开发。 缺点:使用weblogic优先级的应用案例不多～需要验证具体使用策略,和weblogic耦合紧密～完全依赖weblogic,服务请求方发起请求时须指定业务组件实例的级别。 2,自主研发队列机制增加分组和优先级处理:通过队列和连接适配器控制服务在请求和响应按照不同分组和不同级别执行。 优点:完全自主～按照JCA规范,服务请求方无需关心优先级～通过应用集成平台本身配臵实现。 缺点:技术上有难度～存在技术风险,工作量大～需要保障稳定性和性能。 建议先采用方案1过渡～最终过渡为方案2。 ,3,配臵管理 完善超时配臵功能界面等～完善现有功能界面。 增加流量配臵功能界面等～根据需求增加功能界面。 ,4,服务监控 完善服务的运行状态、运行效率、运行是否有错误等的监控。若有问题及时告警～降低运维压力。 28 ,5,服务编排 针对现有服务提供XML报文内容的输入输出处理～也能够把多个服务按照一定规则串接组合起来。编排后的服务作为一个新的服务暴露出来～且对原来的服务代码无须修改。 应用集成平台需支持服务编排功能～但是此功能实现优先级低～在遇到有需要业务场景时使用。 除了上述应用集成平台具体改进措施～还需要加强应用集成平台规范的执行完善和各集成方的协调配合。 ,1,需要不断完善和遵照执行的应用集成平台规范有: 1,GT3-HX-ZJ-应用集成平台接口规范 2,GT3-HX-ZJ-应用集成平台接入规范 3,GT3-HX-ZJ-应用集成平台数据定义规范 4,GT3-HX-ZJ-应用集成平台数据交换规范 ,2,各业务系统需要对服务高度抽象梳理～对各种系统消费方提供的服务尽量保持一致～并尽量减少系统之间减少次数。 ,3,各方协调配臵好超时时间。 ,三,工作流方面 1. 存在问题 工作流系统是金税三期基础软件平台中的重要组成部分。金税三期系统采用了中创公司提供的工作流软件InforSuite Flow～该软件已在多个大型信息系统项目中应 29 用～它是遵循WFMC规范、支持采用XPDL形式XML进行流程定义的工作流中间件～为工作流自动化及流程再造提供基础平台～为金税三期工程提供基础的、统一的流程管理平台。该工作流产品结构如图所示: 图7.1 InforSuite FS产品架构 InforSuite Flow工作流软件提供了统一的BS流程建模平台～可以用于累积业务流程模型～并可便于服用业务模型。流程建模平台功能众多～包含了流程分级定义、下发、逐级个性化扩展定义同一业务流程等特色功能。 在金税三期中使用工作流工具的目的是增强征管系统的适应性～有效支持业务由职能导向转变为流程导向～由结果监督转变为过程监督。工作流软件被用于支撑金税三期工程核心征管、个税、行政办公、纳税服务、管理决策等多个项目～各项目对InforSuite Flow工作流软件进行了集成～并分别对工具相关功能进行了封装或个性化扩展～构建了各 30 自的工作流框架。 目前核心征管系统的各个应用域分别有对应的工作流域～工作流域主要涵盖了工作流服务框架及工作流引擎和工作流数据库。简单来说～核心征管系统的工作流的部署方式是“多实例多数据库”。 个人税收管理系统则采用了“多实例单数据库”的工作流部署方式～个税系统各应用域内嵌了工作流服务框架及工作流引擎～但共享一个数据库。 图7.2 金税三期核心征管系统工作流架构概要示意图 金税三期系统用户最常用的功能就是打开待办任务列表或在办任务列表～在办理流程性事务时大量的使用到推送功能～而这两者都是由工作流系统来承载、实现的～对于前台办税的纳税人而言～办事是否便捷、税务机关服务是否高 31 效优质～很大程度上是由工作流框架和工作流引擎的功能、性能和开发规范性直接决定的～税务系统内部用户的用户体验也与之息息相关。 从目前已上线单位的反映和双轨测试环境实际体验来看～目前金税三期工作流系统存在以下突出问题: 一是初始化配臵特别复杂。 当前～工作流配臵方面主要存在的问题有三点:一是相关的初始化配臵非常复杂～工作量大:初始化配臵极为繁琐～耗时很长。金三系统在工作流配臵上有着数倍于大集中系统的工作量:流程类工作建模中需要额外维护职能树～工作流节点的角色对应关系、表单路径、回调服务与关联流程等内容,非流程类税务事项也需要额外维护角色与税务事项对应关系以及职能树相关的内容。整个金三系统的流程类工作流建模工作量复杂度可以表达为如下: O,流程环节节点数×职能树数目×税务机关×岗位数目×角色×表单路径×回调服务×关联流程×操作机关,～对于非流程类事项～其不涉及具体的工作流配臵～而是使用特定的角色对应的功能模块进行实现～因此其复杂度同理表达如下: O,非流程类事项数×职能树数目×税务机关×岗位数目×角色,,二是因配臵而产生的运行出错概率极高～难以在配臵时校验配臵的合法性～降低了初始化工作的效率,三是排查问题的难度大。初始化工作流的配臵工作包含了工作流图绘制以及每个节 32 点的推送规则、标签规则、事件规则、时间期限的配臵等工作。 二是健壮性不佳～待办事宜可能丢失、延迟～偶有出现事务不完整问题～错误处理机制不完备。 在总局集中版本运行期间～遇到过较多的由于JMS消息延时所产生的阻塞问题～造成“待办门户无法及时展现待办任务、甚至一直收不到”～或者是“待办任务点击异常后任务消失或者仍然存在～再次点击仍然异常”、“在流程监控能看到某任务～但在待办事宜中却找不到对应任务”等现象,发生过一次点击后～业务数据、流程数据处理结果不一致的情况～且错误处理机制未能及时解决此类事务不一致的问题。 三是易用性不佳～部分功能不人性化。 部分单位的同一部门、同一岗位的人员数量较多,广州下属区局的大厅集中办公～约有几百人,～推送时选择下一环节办理人员时需拖拽查找～无法通过输入拼音首字母或税务人员代码来快速定位,部分流程结束后～系统自动触发了关联流程～此时～无法手工选择关联流程推送人员。 四是部分功能缺失～或尚待改进完善。 未实现批量审批～例如出口退税～影响基层工作效率,当操作员离职转岗且未办结当前任务时～缺少功能来进行转办～亦缺少相应监控预警功能,缺少流程图反向查找功能～ 33 当流程图配臵好发布以后～目前没有一个好的功能来查询某流程图的原始流程图存在于BS设计器中何处～以方便检索、基于原流程图进行修改,未能实现流程定义在不同系统环境和不同上线单位之间的导入和导出,跨系统定制流程图支持度不高～目前金三新建系统采用统一的建模工具建模并制作相关规则～再为其他系统进行数据同步～由于在引擎的流程图模型管理中针对建模库无实例数据的流程图采用的是覆盖操作～会导致目标方流程图的历史版本丢失～需要引擎解决,流程分支变量配臵不便～绘制流程图时～往往需要用到分支变量～但目前对业务用例的参数管理不够～会导致绘制时不知道哪些参数在当前业务流程中可以使用～也不知道该如何使用,缺少供核心以外的应用系统发布 工作流程 财务工作流程表财务工作流程怎么写财务工作流程图财务工作流程及制度公司财务工作流程 模型的应用功能,缺少融合查询功能～因目前工作流系统是多应用、多数据库实例部署～操作员无法便捷的查找到可能分散在不同应用域的某个流程之状态～无法在单一功能里实现各应用域流程的统一查询与管理～增加了操作员的负担、增加了引起误解的可能。 五是职责分工不合理,文档材料不完备～系统出现过宕机事故～管理方面存在不足。 初始化建模工作量大且复杂～较难配臵～从现实出发～要明确划分乙方公司与省级以下用户之间的职责范围,各乙方公司未给出回调服务、关联流程等工作流配臵的完整说明 34 文档,2014年1月出现过工作流系统宕机的情况. 通过对典型业务场景的分析～工作流系统的稳定性、功能性和易用性问题对目前金税三期应用系统的内外部用户体验造成了不小的影响。在省级集中部署后～这个问题会更加突出。省级集中并不能自动的同时解决系统的稳定性、功能性和易用性等问题。在我们对金税三期各应用系统和数据库简化合并部署的前提下～减少了系统间的耦合度～可能可以提升部分方面的性能～但稳定性问题、功能性问题和易用性问题将更加突出。 2. 原因分析 通过分析～造成前述问题的主要原因有以下三方面: 一是技术方面。 ,1,待办事宜的集成方式复杂。金税三期系统的待办事宜的集成选择了“推”模式～各应用系统将待办任务推送给工作门户。选择这种方案的初衷在于用户体验比较好。具体技术实现时～首先由总局部署的工作流引擎发起推送待办的事件～然后工作流框架将其转换为JMS消息～发送到ESB～然后传递到省级集成平台～最后落地到省级集成平台库～由门户来进行展现。产生JMS消息延时并导致待办信息无法及时展现的主要原因有三:异步消息机制存在延迟～有时候消息队列堵塞～造成任务无法在规定时间到达省局门户,网络链路距离长～延时大～网络可能出现丢包,当应用了多JMS 35 队列且先后发出多个有先后顺序要求的JMS消息时～无法保障整体先进先出～目前的实现仅能保证每个队列先进先出。 ,2,事务完整性保障机制不佳～系统错误处理机制不完善。为保证JMS消息,被推送的任务,的可靠性～目前通过开发待办事宜对账程序将业务工作门户中的待办任务数据与各应用系统工作流数据库数据进行对账～待办事宜对账程序通过EJB接口调用工作流对账服务的EJB服务查询应用系统的工作流待办事宜数据～但有效性未得到验证。目前没有完整有效的保障事务完整性的机制～在存在跨域调用时～没有使用JTA、XA数据源、多阶段提交等方式在事中保障事务完整性～也没有构建充足的自动化补偿功能在事后恢复事务完整性。 ,3,工作流框架和工作流引擎功能不足～未能及时根据需要完善相关功能。 二是业务方面。总局的流程规范与各上线单位实际操作存在差异～加上厂商和上线单位理解上的差异～导致系统中配臵的工作流程过多而且过于复杂。 三是实施管理方面。 ,1,开发配臵工作与用户配臵工作未能合理划分～导致均需要用户进行配臵～增加用户工作量～而且出错率高～效果不好。 ,2,需求分析存在不足。部分业务需求在实现时～设 36 计出来的逻辑较为复杂～在程序实现时涉及到多次跨域调用～客观上导致未能良好的保证工作流与业务数据的一致性、事务的完整性。 ,3,业务应用与工作流框架功能分工落实不严～存在个别业务应用没有充分利用工作流框架的功能而自行实现部分工作流功能。 3. 调整目标 工作流系统的优化直接关系到金税三期主体业务功能的正常运转～关系到构建和谐征纳关系～关系到落实“两个减负”～因此需要重视对系统功能性与非功能性需求,或称质量服务需求,的满足～要做到运行质量,易用性、健壮性、稳定性、效率等,与发展质量,可测试性、可维护性、可扩展性、可伸缩性、兼容性,并重～其中需要特别重视确保系统的健壮性、稳定性～具体目标如下: ,1,优化工作流相关功能实现, ,2,提升系统运行效率～优化工作流应用架构。 ,3,增强健壮性～完善错误处理机制, ,4,增强易用性～改善用户体验。提供合理的默认值～记忆用户选择～支持全键盘操作等～降低用户的学习和适应难度, ,5,增强可维护性～完善配臵功能～合理切分工作职责。 37 4. 优化方案 为了达到以上目标～解决目前工作流系统存在的各种问题～提升用户体验～需要从技术、业务和管理三方同时采取措施进行调整优化。 一是技术方面。 ,1,优化应用架构以配合工作流的相关工作机制。 首先要确定是否继续使用JMS消息传递待办任务。若继续使用～则需设计、完善异步消息完整性、可靠性保障机制并进行稳定性、完整性验证～需要将JMS消息服务器细分, 按业务/区域/消息量等规则部署多个消息服务器～确保消息始终保持发送时的先后顺序,若不保留～则改用实时调用。实时调用的优点在于结构简单、排错简单、可靠性较高且更为可控～任务可以实时在门户展现～缺点在于需要量化的验证性能是否能满足省级集中需求,保留JMS的优缺点基本与实时调用的优缺点相反。 其次～可以将工作流引擎库与生产库合并。在生产系统调用工作流引擎API的时候～改为外部传入数据库连接的模式～使得工作流引擎与生产系统保持在一个数据库事务中。这样可以部分的减少事务不一致的可能性～更好的提高内外部用户的体验～缺点在于可能对数据库的压力较大～需要进行量化验证。 再次～应完善系统对事务不一致的处理机制、提高程序 38 健壮性、完善异常处理能力、完善补偿用例的实现。在功能用例实现时～应遵循的原则如下:事务嵌套、跨应用调用不超过一层。经分析～工作流应用有两种架构部署方案～分述如下: 第一种是采用嵌入式～嵌入业务应用工程中～不单独部署。此种选择的风险点有:可能遇到jar包冲突问题,在现有需求实现方式下～并不能彻底解决事务不一致问题～需测试验证。 第二种是仍然采用单独部署工作流域。选择该方案时时～仍然会存在跨域调用。因此～为了保证数据在多个参与的数据源中的一致性,需要用到JTA来控制事务,参与的数据源也需要支持X/Open协议(两阶段提交)。据了解～大连地税网络发票系统与核心征管系统之间的跨域调用使用了JTA来保证事务一致性～此外国税系统也有应用的案例。该方案有如下两点需要注意:一是JTA分布式事务提交需要框架支持,二是两阶段提交会影响性能～特别是两个事务处理时间比较长的情况下可能会有性能压力～需要进行基准性能测试以确定特定硬件配臵条件下是否能满足性能需求, 对于跨域调用～除使用JTA来控制事务外～还应开发业务手动补偿用例以及自动化补偿方式～对不一致事务采用补偿机制解决～此方式的风险在于需要开发的补偿用例过多～容易遗漏,并完善后台监控的功能～在发生不一致时～保存 39 完整的不一致现场～以便于后台运维处理。 第四～清理工作流域相关的数据同步机制。避免使用数据同步机制来实现少量数据的交互～改为采用实时同步调用方式。可广泛参考目前的省级集中系统的类似场景及其解决方案。 ,2,优化工作流框架～包括功能完善、错误处理机制的完善、事务完整性保障机制的完善、配臵功能完善。 首先是增加模拟运行功能～实现在流程发布之前～流程能够自动模拟运行～减少人工测试工作量。工作流应该可以提供配臵验证或提供较为人性化的提示功能～包括:验证主工作流是否配臵正确,验证各选项是否配臵正确,验证关联选项是否配臵正确等。 其次是增加工作流配臵信息变更、发布、导入导出功能。工作流配臵信息变更的维护工作目前需要各单位根据工作流配臵变更单进行维护～应开发一个发布功能～可以生成相关sql或者dmp文件～随版本发布各个环境～以此减少配臵的工作量、保证与java代码版本的一致性～并减少由于人工维护造成的数据质量问题。 再次是提供融合查询功能。无论使用单引擎单数据库、多引擎单数据库或多引擎多数据库的部署方式～均应在门户向用户提供融合查询～一次查询即可查找到各业务域的工作流转情况。 40 第四是建立、完善健壮性自动冲正,补偿,机制。增加自动冲正,补偿,功能～完善、建立自动化的错误、异常处理机制～排除因异常处理不严谨所导致的数据不一致问题～保障业务数据和工作流引擎数据的一致性。 第五是完善基础控件～智能化展现操作界面。优化备选人员的显示顺序。可选的方案如下: 1,支持历史记忆功能。包括:根据上一次本流程本环节推送时～默认选择上次选择的办理人员。根据历史选择的次数～选择次数较多的排名靠前。 2,支持用户设臵常用备选人。包括:每个用户在每个流程和环节可以设臵常用的备选人～常用备选人排名靠前～如果不设臵～则按普通排序。 3,支持手工输入人员编号和人员姓名～支持系统默认填充～支持模糊查询。 第六是支持无纸化、支持新旧工作流并存、允许操作人员选择关联流程的启动环节之处理人员等。 除了上述六点～还需要在架构调整前～按各种候选调整方案编制各种可能引发故障的测试场景～并依此进行充分验证～根据结果进行测试和持续改进～提升其稳定性和效率～并提交评估报告给甲方,总局与省级税务局,供决策。 工作流与权限是密不可分的～两者具有天然的相关性～应充分采集各省税务机关关于工作流权限配臵方面的意见～ 41 兼顾灵活性、特殊性与普遍性～完善、简化工作流权限配臵模型。举例而言～至少有两个问题需要完善: 一是工作流配臵规则中绝对层级判断需要设臵为对应的机关及其内设部门。对绝对层级判断时～应默认设臵为其对应的机关及其内设部门。 二是机关内设部门的权限默认与所属机关保持一致。在工作流配臵中～应默认使得机关内设部门的权限与所属机关保持一致～如果需要额外调整,部分岗位需要设臵为本部门,～可允许进行设臵修改。相关配臵方式应简洁明了。 ,3,优化工作流引擎。 首先是研究工作流引擎及其数据库实例的参数优化。适当的配臵工作流引擎及其数据库实例的参数～可以极大的降低工作流操作的平均响应时间、提升吞吐量～对整体性能和用户体验有明显提升。 其次是分离工作流数据库里的历史数据与活动数据。参考数据组成果～结合工作流系统实际～制定工作流库历史数据剥离规则和实施策略～确保工作流库性能。 二是业务方面。可以从以下三方面进行调整: ,1,清理、拆解复杂的业务流程～重做相关需求分析～简化设计。 部分业务需求在分析时～设计出来的逻辑较为复杂～在程序实现时涉及到多次跨域调用～违反了“高内聚”、“单一 42 责任”的基本设计原则～客观上导致未能良好的保证工作流与业务数据的一致性、事务的完整性。 应对此类特殊的业务需求重新进行需求分析～针对工作流系统的特点进行优化～力求保证需求点实现时的原子性～实现高度功能内聚～必要时征求各上线单位的业务意见以对业务需求点进行简化或拆解～从而保证事务完整性、数据一致性。 ,2,清理工作流的不合理使用。 一方面避免人为的增加工作流框架的负担～另一方面也减少可能遇到的问题。应严格界定需要使用工作流的场景。对于“即办类”或“单节点”业务～应避免使用工作流来实现。 ,3,保持灵活性。 在工作流相关的业务设计中～应从全国实际情况出发～保持业务涉及的灵活性。如～部分地市县区局的流程和其他县区局流程不一致～需要重新画～需要将允许自行绘制工作流的最小单位设为县区局。 三是管理方面。可以从以下三方面进行调整: ,1,完善工作流系统相关的开发、运维制度。 首先要建立完善的质量保证制度、变更 管理制度 档案管理制度下载食品安全管理制度下载三类维修管理制度下载财务管理制度免费下载安全设施管理制度下载 和版本控制制度～严格执行流程～切实做好质量保证工作。 其次要制定设计、开发、测试规范并严格执行。各乙方 43 项目组应参考业界主流的开发规范编制、完善适合本项目实际情况的设计、开发、测试规范手册并持续改进。在编制过程中应参考的现行软件行业中主要适用的国家标准或行业标准如下: GB/T 8566-2007 信息技术 软件生存周期过程 SJ/T 11375-2007 软件构件产品质量 GB/T 14394-2008 计算机软件可靠性和可维护性管理 GB/T 15532-2008 计算机软件测试规范 GB/T 29832.3-2013 系统与软件可靠性 第3部分:测试方法 ,2,优化流程建模功能～调整流程建模、初始化的职责分工。 目前初始化建模工作量大且复杂～较难配臵。从现实环境出发～要明确划分乙方公司与省级以下用户之间的职责范围。有如下三种可选的解决方案: 第一种:由乙方承担主要的建模责任～省级用户方负责提出具体需求并参与进行配臵工作。由乙方进行业务流程采集后,工作流的标签规则、事件规则配臵等,～进行初始化～再将部分可调整规则,如工作流推送规则,开放给省级用户调整～如果有变更～则根据调整内容走变更流程～由双方协调解决, 第二种:乙方优化流程建模方式～彻底剥离流程表单中 44 流程和业务的现有固化代码～提供向导式建模方式～在每一步都提供充分的提示信息和文档支持～确保在每一时刻出现的多个选项之间能自动根据选择动态enable或disable～实现“可见即可选～可选即可用”, 第三种:乙方分国地税根据已上线省份的配臵情况～提供一套标准的工作流配臵数据:在初始化初期将标准的工作流数据导入系统～上线单位在此基础进行个性化调整配臵。 ,3,建立完备的文档管理制度,配臵管理制度,。 乙方对于工作流相关的角色、岗位、有关说明～应该及时更新和发布相关文档,说明材料,。对于所有的文档材料～应建立维护更新机制～保证文档与实际系统的一致性～并保持需求、设计文档与用例实现的双向可跟踪性。 应针对文档管理制度、配臵管理制度设立相应的质量保证与质量控制的制度～周期性的检查配臵库、文档的内容与形式。在编制文档管理制度的过程中～应参考的现行软件行业中主要适用的国家标准或行业标准如下: GB/T 8567-2006 计算机软件文档编制规范 GB/T 9386-2008 计算机软件测试文档编制规范 GB/T 16680-1996 软件文档管理指南 工作流相关文档应结合已上线省份的实际配臵运行情况进行更新～并将已上线省份的主要配臵信息以及特殊场景的应对方式整理成册～不断充实过程资产。在上线前～乙方 45 应能按需要提供工作流配臵的完整文档。 工作流系统关系重大～在金税三期系统中属于基础性支撑平台～故而需要慎重进行相关决策。在进行框架技术调整、业务调整和管理制度调整的同时～可以开展工作流应用相关的梳理优化工作～具体包括以下几个步骤: 调研目前金三系统用户操作习惯和关注问题。对用户意见进行记录并汇总分析～形成报告。报告应重点从用户反馈中提取功能性与非功能性需求点～并逐一提出解决方案供选择。 继续进行技术和用户测试。组织技术人员和用户进行全面测试～并根据测试反馈继续进行修改和完善。 ,四,Web层框架方面 1. 存在问题 金税三期核心征管系统基于中软睿剑业务基础平台～该平台基于构件技术～架构在分布式应用框架J2EE之上～涵盖了系统开发的各个方面。该平台的Web层提供了一组丰富的页面展现控件和完整的前后台交互逻辑～使开发者可以通过所见即所得的方式快速绘制用户界面并与后台业务用例构件交互。金税三期核心征管系统用户界面表现为这些控件和逻辑的组合～因此该平台Web层的功能、性能和开发规范性直接决定了金税三期核心征管系统的用户体验。 从目前已上线单位的反映和双轨测试环境实际体验来 46 看～该平台Web层存在以下问题: ,1,界面渲染速度慢。根据中软方面说明～用户界面出现“加载中”的红字提示时表示后台数据已经交互完毕～开始Web层界面渲染过程。目前在常见环境下较少页面可以在1秒内渲染完毕供用户操作～大部分页面需要3-5秒甚至更长时间才能渲染完毕～部分复杂页面甚至需要10秒以上才能完整显示～严重影响了系统整体体验和用户操作效率。 ,2,跨浏览器兼容性差。目前金税三期系统在IE8下运行较为正常～在IE其他版本下存在或多或少的兼容性问题。金税三期上线前～大部分税务信息系统要求使用IE6环境～其中部分系统无法支持IE更高版本～如果安装IE8浏览器会导致这些系统无法使用。金税三期在IE6浏览器下存在性能低下～功能出错的问题～虽然经过多次优化依然无法彻底解决。 ,3,页面设计不规范。部分功能布局设臵不合理～在不同分辨率下无法自适应～显示器较小的用户无法显示完整界面。部分功能设计应对大量数据没有进行分页～或页面包含大量隐藏元素等～造成界面卡顿。缺乏用户操作行为的分析和优化～部分界面操作繁琐～无法进行全键盘操作。 通过对典型业务场景的分析～Web层的性能和易用性问题是造成目前金税三期核心征管系统操作效率问题的主要原因之一～尤其在省级集中部署后～这个问题会更加突出。 47 这主要是由于省级集中并不能改善Web层的性能。应用层和数据库简化合并～压力减小后～Web层渲染时间长的问题将更加突出。另外系统正确性和稳定性得到改善后～用户将更加关注易用性的问题。 2. 原因分析 通过分析～造成这些问题的主要原因有以下两方面: ,1,Web层框架技术不够完善。 Web层框架除核心部分采用成熟第三方组件外～其余均为中软自行研发～目前在性能、兼容性上仍然存在不足～尤其体现在页面渲染时间过长和对IE6优化不够上。Web层缺乏统一的布局组件和Tab键顺序切换等功能～需要由具体开发人员根据习惯和偏好自行处理。Web层框架没有引入较新的Web层设计思路和实现方法～缺乏后续的发展规划和演进路线。 ,2,缺乏统一的开发规范和用户体验指引。 具体业务功能的开发人员能力和习惯存在差异～导致系统界面统一性不强～部分页面设计不科学、不合理～用户需要适应多种风格的操作界面～并在鼠标和键盘间频繁切换～严重影响了效率。缺乏完善的代码审查机制～部分导致界面相应缓慢和出错的原因没有被及时发现～遗留到黑盒测试时才暴露～由于测试者难以了解页面的处理机制～部分问题被错误归类～没有得到彻底解决。 48 3. 调整目标 Web层的优化直接关系到用户对金税三期核心征管系统的印象和评价～在解决系统正确性和稳定性的同时～有必要对Web层进行全面的梳理和优化～具体目标如下: ,1,实现页面的快速展现。系统完成后台交互后可以在1-3秒内完成页面的渲染和展现～让用户开始进行业务操作。 ,2,实现统一的页面风格和操作方式。规范页面的布局、操作名称和操作方向～降低用户的学习和适应难度。 ,3,优化用户操作体验。优化操作热点的布局～提供合理的默认值～记忆用户选择～支持全键盘操作等～提升用户友好度～减少界面操作时间。 ,4,提升系统兼容性。实现对Windows XP、Windows 7、8操作系统和IE6-11浏览器环境的完善支持～提升运行的稳定性～降低客户端环境配臵的难度。 4. 优化方案 为了达到以上目标～解决目前Web层存在的各种问题～提升用户体验～建议采用以下调整方案: ,1,实施技术调整 1,优化Web层框架。考察当前业界主流开源Web层框架的性能和功能～参照吸收其设计思路和实现方案～明确优化完善Web层框架的目标和路线图～全面提升Web层框架的 49 功能、性能和兼容性～达到并超越其他税务信息系统的当前水平。该项优化的难度和工作量较大～需要进行合理规划和安排。由于现有Web层框架的实现方式较难在IE6下获得良好性能～单纯进行优化无法达到所有调整目标～需要配合其他调整措施。 2,安装插件。由于Windows操作系统只能同时安装一个版本的IE浏览器～在保障IE6环境业务系统正常运行的要求下～可以通过安装渲染引擎IE插件,chromeframe,的方式～实现双核心浏览器～由集成门户区分金税三期系统页面和遗留系统页面～分别调用不同内核进行渲染。经过测试～引入新内核可以立即大幅提升页面渲染速度～同时保证现有系统的正常运行～实施工作量较小。未来可以使用新内核的高级特性支持更美观易用的用户界面设计～将用户体验提升到全新层次。但安装新的插件会导致客户端IE运行环境更为复杂～可能导致新的兼容性问题～需要进行全面测试。插件为第三方公司产品,google,～目前无法获得支持和服务。 50 图7.3 客户端安装IE插件,chromeframe,后应用场景示意图 3)开发定制客户端。为了解决上述第二点的问题～后续可以改为通过定制客户端同时集成高性能开源浏览器内核,webkit,和系统自带的IE6内核～客户端提供功能集成界面～区分金税三期系统功能和遗留系统功能～分别调用不同内核进行渲染。客户端可以提供本地程序和硬件的访问～并避免干扰浏览器配臵。该方案构建强大的系统客户端运行平台～引入功能强大的高性能浏览器内核～并整合硬件和操作系统资源～为进一步优化用户体验提供支持。同时独立的客户端脱离了客户端浏览器环境～避免了复杂的兼容性问题。该方案需要进行专项开发～工作量较大～需要较长周期。客户端需要进行部署和维护。 51 ,2,强化管理措施 在进行框架技术调整的同时可以开展功能页面的梳理优化工作～具体包括以下几个步骤: 1,调研目前金三系统用户操作习惯和关注问题。对典型页面的操作顺序、操作热点、步骤耗时和用户意见进行记录并汇总分析～形成报告。 2,完善页面开发设计规范。根据调研结果制定统一的页面布局和操作规范～明确屏幕分辨率、响应时间、键盘操作方式等非功能性要求～并对开发人员进行指导。 3,对照开发规范～全面梳理调整现有页面设计实现。逐个检查目前系统的用户界面～对不满足规范要求的项目进行修改。对于共性问题考虑在框架层面统一实现 4,进行技术和用户测试。组织技术人员和用户进行全面测试～并根据测试反馈继续进行修改和完善。 八、项目管控方案 为确保金税三期工程顺利上线～做好优化实施期间金税三期工程各项目的管控工作～保障金税三期工程“3+2”阶段的上线实施工作～按照“统一规范、分级管理、细节分工、责任到人、狠抓落实、注重安全、效率优先”的原则～制定优化实施阶段项目管控方案。 52 ,一,概述 1. 金税三期总体组织结构 优化实施阶段是金税三期工程中的关键性阶段～既依赖于前期的工作成果～同时也需要各职能组的协力配合～也需要各项目组的大力支持才能顺利进行～为方便开展工作～通过下图明确优化实施工作组在金税三期中的总体位臵。 职能组 实施工作组 项目组 图8.1 金税三期总体组织结构图 金税三期现阶段可划分为三类工作组:职能组、实施工作组和项目组。优化实施组位于实施工作组中～是本方案的执行主体。 2. 优化实施工作组和各组关系说明 金税三期优化实施阶段～信息办将带领各组相互协作支 53 持～通过后勤支持、协助、进度监管、审核等手段实现通力配合～但具体优化实施工作由实施工作组中的优化实施工作组负责。详见下图: 职能组 实施组 项目组 技术环境保障实核心征管及应用总集成项目组 综合组 施工作组 个人税收管理项目组 后勤支持 , 项目管理组 管理决策1-3包项目组 进展汇报 , 优化实施工 指导 配合协助 架构管控组 管控 纳税服务项目组 作组 配合协助 外部信息交换项目组 , 业务管控组 技术审核 行政管理项目组 运维保障实施 工作组 采购组 网络发票项目组 图8.2 金税三期优化实施组与其它职能组和项目组关系图 3. 适用范围 本方案适用于金税三期优化实施阶段中参与的国家税务总局人员、各试点省市国、地税人员及参与项目建设的乙方公司人员。同时适用于优化实施阶段的整体项目管理、系统需求、概要设计、详细设计、数据库设计、测试、部署环境及配臵管理等全软件生命周期流程管控。 54 ,二,组织结构及人员保障 1. 组织架构 优化实施期间的项目管控工作由国家税务总局信息办、总局各司局、试点单位和各厂商组成。 总体架构图如下: 图8.3 金税三期优化实施组总体架构图 金税三期工程由国家税务总局信息办统一指挥～第一层为管控已上线省市的运维保障实施工作组、准备3+2上线工作的优化实施工作组及负责总体环境保障的技术环境保障实施工作组。 为保证全面、高效的管控优化实施工作～优化实施工作组下设总体组、应用管控组、数据管控组、测试管控组、配臵管理组。 2. 工作职责 ,1,总体组 55 负责全面优化项目的整体实施管理工作。具体为: 1,制定并动态完善项目总体 计划 项目进度计划表范例计划下载计划下载计划下载课程教学计划下载 ～全面负责项目的实施进度,制定项目管理规范和各组职责分工～统筹协调各小组开展工作和组间沟通, 2,根据项目里程碑计划及时召开审查会议～组织项目阶段评审～督导项目的实施进度～及时发现问题、解决问题, 3,定期向PMO ,信息化领导小组办公室,汇报项目的实施进度, 4,负责与总局各司局、金税三期其他职能组沟通。 ,2,应用管控组 负责优化项目所属各系统的各阶段管控。具体为: 1,根据项目计划～按时收集并审核各项目组提交的总体架构设计、需求分析、概要设计和详细设计等方案, 2,负责审核各项目组提交的应用架构和关键应用技术～包括服务总线、开发框架、工作流、权限、与遗留系统和本地软件的接入方案等, 3,负责协调各系统的各项目组解决设计及开发工作中的问题, 4,负责督导各项目组的应用相关工作实施进度～发现问题及时向总体组报告。 ,3,数据管控组 负责项目各系统的数据管控工作。具体为: 56 1,负责审核各项目组提交的数据架构设计、数据模型标准及规范、数据库及数据仓库建设规划、数据同步及上传分发、数据清洗、数据备份、数据质量检测、数据模型变更等方案, 2,负责协调各系统的各项目组解决数据库设计及建设工作中的问题, 3,负责督导各项目组的数据相关工作实施进度～发现问题及时向总体组报告。 ,4,测试管控组 负责项目各系统的测试管控工作。具体为: 1,负责审定各项目组提交的各系统的内部测试方案～评估测试范围、测试结果以及测试的有效性, 2,负责审核各项目组提交的各系统的测试报告, 3,负责督导各项目组的测试相关工作实施进度, 4,在各项目组完成内部测试后～负责组织协调各试点单位完成系统用户测试～协调与各项目组解决测试中的问题, 5,就各系统是否通过用户测试向总体组负责。 ,5,配臵管理组 负责项目的配臵管理、变更控制等工作～并协助总体组制定各系统的部署方案。具体为: 1,负责组织设计配臵项～制定配臵管理规范和策略～ 57 创建和管理配臵管理库, 2,负责项目的日常配臵管理工作和源代码、版本的统一管理工作, 3,负责管控各种系统环境,开发、测试、试运行等,的软硬件资源文档～管理各种产出物,环境配臵说明文档、相关用户文档、各阶段性的产出文档等,, 4,负责制定各系统的部署方案, 5,负责定期审核和评估配臵计划的落实情况。 3. 人员分工 ,1,总体组,17人, 组长:苏小全 成员:李志、朱斌、鲁钰锋、涂俭、黄海军、陈冰、周昊、专业项目经理1人及河南、内蒙、山东、山西国、地税人员各1人。划分以下小组: 项目管理小组:苏小全、专业项目经理1人和专职项目管理人员两名。 架构管理小组:黄海军和周昊。 技术专家小组:集中各组技术骨干形成的一个虚拟小组。 评审专家组:由各试点单位业务和技术专家组成。 ,2,应用管控组,20人, 组长:李朝学、黄世能 58 ,3,数据管控组,20人, 组长:邱洋、张孟雷 ,4,测试管控组,10人, 组长:建议由试点省征科处级干部担任 副组长:熟悉测试理论并由实战经验的IT人员1人。 ,5,配臵管理组,5人, 4. 人员能力要求 岗位 能力要求 精通项目管理方法～精通项目计划制定、项目资 源组织、能在实施过程中对项目提供实施指导、项目经理岗 项目进程推动、组织协调项目全程管理工作～熟 练使用Office软件等工具。 精通税务行业核心业务～对税务行业业务有独到应用管控岗1 见解～税务行业从业5年以上～从事过业务分析、 系统分析工作。 精通税务行业核心业务～税务行业从业5年以上～应用管控岗2 从事过业务分析、系统分析工作。 精通税务行业核心业务～税务行业从业2年以上～应用管控岗3 从事过税务行业的软件开发项目～掌握面向对象 的设计方法及基于SOA的设计风格～精通Java 59 开发语言。 精通税务行业核心业务～精通数据库的设计、开 发、维护、优化～精通Oracle数据库～精通至少数据管控岗 一种数据库建模工具～从事过税务核心系统数据 模型设计工作。 熟练掌握税务行业核心业务～精通软件测试理论～测试管控岗 掌握功能测试、性能测试及健壮性测试方法～了 解QC等缺陷管理工具。 精通项目开发配臵管理工作～包括基线管理、版 本管理、发布管理、变更管理、配臵审计等～能配臵管理岗 制定配臵管理规范～会配臵管理工具的安装、配 臵、配臵库备份等。 表8.1 金税三期总体组织结构图 ,三,管控流程 1. 总体项目管控流程概览 实施优化阶段项目管控工作可以分三个阶段进行～分别为第一阶段优化方案制定～第二阶段优化方案实施～第三阶段优化版本上线推广。 具体流程图如下: 60 金税三期优化实施阶段项目管控流程 制定数据制定测试制定应用设计配置项第提出用户需求制定管控方案管控方案管控方案管控方案一制定优化方案审核待解决问制定配置提出待解审核应用审核架构审核数据阶题并入配置库管理方案决问题优化方案优化方案优化方案段)组织专家评创建配置库制审优化方案订优基线产物入库提交基线产物化方优化方案上督促、审计文案报信息办档入库情况) 审核实施方案审核实施方案审核实施方案审核实施方案制定实施方案实施方案入库架构部分应用部分测试部分数据部分提出用户需求组织专家评需求分析及专需求分析审需求分析家意见入库确认用户需求组织专家评概要设计及专组织数据概要实现审概要设计架构评审家意见入库 组织测试测试方案及专测试方案设计第方案评审家意见入库二阶组织专家评组织数据详细设计及专详细设计段审详细设计模型评审家意见入库)测试用例及专组织测试测试用例设计优用例评审家意见入库化组织里程碑后里程碑代码及实编码实现代码走查走查结果入库施)测试报告及审组织测试实验室测试报告审核核意见入库 版本发布组织用户测试版本统一管理 形成用户测试环境用户测试测试报告规划管理审核测试报告测试报告及审并上报信息办核意见入库试点单位软硬审批软硬件软硬件环境规件需求方案需求方案划管理 安装及用户培软硬件安装安装实施组织用户培训训手册入库第三用户培训阶段巡检结果及问组织试运行期组织试运行期收集用户反馈)上线试运行题清单入库间应用巡检间数据库巡检形成问题清单推广审核试运行报组织生成试运试运行报告及上告并报信息办行报告审核意见入库线)按信息办批示审计配置库形意见整改上线成配置报告 图8.4 金税三期优化实施阶段项目管控流程 61 ,1,第一阶段工作流程: 1,优化实施组组织结构的建设～明确组织分工。 2,组织各厂商、试点单位及相关司局从应用架构、数据架构关键技术、用户体验、应用集成、部署及运维几方面进行优化内容讨论。 3,各厂商及相关司局提出优化建议。 4,总体组分析、汇总提炼形成优化方案。 5,优化方案报信息办审核。 6,根据审核意见修改优化方案。 7,优化方案发布。 ,2,第二阶段工作流程: 1,各项目组根据优化方案内容～组织编写各项目的优化实施方案。 2,各项目组将形成的优化实施方案报应用管控组及数据管控组审核。 3,各项目根据优化方案及各自的优化实施方案开展各应用项目的版本优化。 4,各项目组将经过实验室测试的优化软件版本、源代码、用户手册、测试用例、测试报告等相关材料提交配臵管理组。 5,测试管理组组织试点单位进行用户测试～并将测试报告上报总体组。 62 6,开发商修复用户测试缺陷～并提交新版本入配臵库。 7,重复5～6直到版本稳定达到测试标准要求～形成发布版本提交配臵管理组。 8,总体组报信息办审批后进行版本发布～开始试点上线推广。 ,3,第三阶段上线推广: 1,试点单位规划软硬件需求提交配臵管理组审核。 2,总体组组织评审。 3,试点省市开展软件安装工作。 4,试点单位进行试运行工作～由应用管控组及试点单位对试运行状况进行评估～并形成评估报告。 5,由总体组将试运行评估报告提交给信息办。 6,总体组根据信息办的审核意见～形成进一步优化整改方案。 7,试运行结束后将应用系统交付相关部门进行日常运维。 2. 需求分析管控流程 需求分析阶段是由业务需求转化为系统需求的阶段～这一过程的结果就是《软件需求规格说明书》。在《软件需求规格说明书》中需要明确系统功能、性能指标、可靠性等多方面的规格化需求～建立业务用例图包括所有角色～确定软件的主要功能。 63 项目组编制《需求规格说明书》提交应用管控组审核～应用管控组将《需求规格说明书》及相关审核报告上传到配臵库。具体流程如下: 需求分析 提交需求确认反馈确认单 审核需求规内部评审格说明书 评审意见组织评审入库 通过 需求规格说组长审批明书入库 图8.5 金税三期优化实施阶段需求分析管控流程 注:项目组需求分析过程中待确认的问题～由项目组需求人员形成需求确认单提交业务组确认并反馈给项目组～需求分析经过项目组的内部评审后提交应用管控组审核～并由应用管控组组织评审需求分析文档～评审通过的需求文档会同意见提交配臵库存档。 3. 概要设计管控流程 系统设计阶段是从实现的角度开发针对客户需求的解决方案～完成软件的架构设计。这一阶段需要产出《概要设计说明书》～并明确关键技术的设计和验证机制～明确系统 64 未来的部署和实施视图、逻辑视图、功能视图等。考虑系统的架构质量～解决和实现系统非功能性需求的目标。 项目组产出的《概要设计说明书》需要通过总体组组织的评审。总体组将《概要设计说明书》和评审意见上传至配臵库。 具体流程如下图: 概要设计 审核概要设审核概要设内部评审计应用部分计数据部分 评审意见组织概要设入库计评审 通过 概要设计文组长审批档入库 图8.6 金税三期优化实施阶段概要设计管控流程 注:概要设计管控由总体组的架构管理组负责～审核 及评审需要应用管控组、数据管控组、测试管控组参与并 参与评审。同时数据管控组还需要单独组织数据架构评 审。 4. 详细设计管控流程 详细设计～是以概要设计的设计文档和需求规格说明书 65 系列文档为输入～进行详细分析、设计的过程。内容包括:用例设计、数据模型设计、界面设计。这一阶段需要产出《详细设计说明书》。 项目组产出的《详细设计说明书》需要通过应用管控组组织的评审和数据管控组组织的数据模型评审。应用管控组及数据管控组对详细设计阶段的产出物进行评估～包括类图、时序图等～对数据模型设计、界面设计的偏离度进行评估。应用管控组将《详细设计说明书》和评审意见上传至配臵库。 具体流程如下图: 详细设计 审核详细设审核详细设内部评审计应用部分计数据部分 组织数据模评审意见组织详细设型评审入库计评审 通过通过 详细设计文组长审批组长审批档入库 图8.7 金税三期优化实施阶段详细设计管控流程 注:详细设计的评审由应用管控组组织～同时数据管 控组需要组织数据模型评审～两个组的评审意见提交入配 66 臵库～评审通过后详细设计文档也需要提交入配臵库。 5. 测试管控流程 测试管理工作流程说明如下: ,1,资料提交环节 1,项目组在执行测试之前～按要求提交《金税三期XX项目测试方案》,以下简称《方案》,、《金税三期XX项目测试用例》,以下简称《用例》,及其相关的附列资料～需提交的资料主要包括:测试计划,人员组织安排,测试方案,详细说明测试的对象、测试方法/技术、测试过程、测试环境等,,测试用例等。 2,测试方案、测试用例及其附列资料必须在项目组执行测试前提交～审核通过后方可执行测试, 3,项目组提交的资料不符合审核要求的～应配合测试管控组及时提交补充资料～直至完成测试审核。 ,2,资料接收环节 1,测试管控组对项目组提交的测试方案、测试用例及其附列资料的规范性、完整性进行审核, 2,提交的资料不符合要求的～测试管控组应及时反馈至项目组接口人～直至提交的资料符合要求为止, 3,测试管控组对资料审核通过后～执行方案审核环节。 ,3,方案审核环节 1,测试管控组依据项目组提交的资料～从时间、测试 67 工作安排的合理性、测试的目标、测试的策略、测试的范围、测试的覆盖度、测试的指标、测试用例的合理性等方面进行全面审核, 2,涉及到业务层面的审核工作由应用管控组配合测试管控组完成, 3,测试管控组在审核过程中～可召集专题会议对有关问题进行质询～项目组和上线单位应指派相关人员与会, 4,测试方案和测试用例审核完成并填写《金税工程三期测试监管记录表》,以下简称《测试监管表》,相关部分内容后～执行风险评估环节。 ,4,风险评估环节 1,测试管控组根据测试资料审核和专题会议结果～对测试所涉及的各层面风险进行全面评估, 2,测试管控组根据风险评估结果～判断是否执行测试,允许则通知项目组执行测试程序～评估不通过则反馈至项目组接口人, 3,测试管控组根据风险评估结果～填写《测试监管表》相关部分内容。 ,5,过程监管环节 1,项目组负责测试工作的具体执行～上线单位配合项目组完成测试工作。 2,项目组执行测试时～测试管控组对测试过程进行全 68 过程监管, 3,测试管控组对测试进行日常监管～包括测试进度、测试中暴露的问题、可能的风险等, 4,项目组每日向测试管控组提交测试日报。 5,必要时～测试管控组会依据测试用例对测试执行情况进行抽检～验证测试质量, 6,测试结束后～进入报告评估环节。 ,6,报告评估环节 1,项目组完成测试后～应向测试管控组提交测试结果报告～对测试的执行情况、测试暴露的问题、测试的指标结果等进行详细的报告, 2,测试管控组依据项目组提交的测试报告～并结合测试过程监管情况～对测试结果进行评估, 3,评估完成后～由测试管控组填写《测试监管表》相关部分内容。 6. 配臵管理流程 配臵管控的目的是利用配臵管理工具对产出文档进行管理～确保优化实施阶段各项目文档资料在整个生命周期中都是完整、可控制且可追溯的。配臵库由配臵管理组指定各项目的配臵管理员～只有配臵管理员有修改权限～其他成员仅有只读权限且由配臵管理员统一分配。配臵管理组需要提前设计好配臵项～并提出配臵管理计划由组长审批后～经由 69 总体组确认～即可创建配臵库并进行产物提交～且定期进行配臵库的审计和管理形成审计报告提交组长审批～在项目过程中也要负责督促其他管控组及项目组及时提交阶段产物入配臵库。 配臵管理组同时负责版本发布过程中的系统环境管理～由乙方发布版本导致的开发、测试、试运行等系统环境的软硬件发生变更～应由试点单位提出变更申请提交总体组审批～并由配臵管理组进行规划分配～经配臵管理组组长审批后～协调技术环境保障实施工作组提供相应的软硬件环境～试点单位完成软硬件环境变更并更新环境说明到配臵管理组～经配臵管理组审核后入配臵库。总体工作流程如下: 配置项设计及计划 组长审批 创建配置库阶段产物及评审意见及评审意见及文档提交文档提交文档提交定期检查督促文档入库软硬件环境需求版本发布 软硬件环软硬件环境定期审计境需求审核资源规划 组长审批 图8.8 金税三期优化实施阶段配臵管理管控流程 7. 版本发布管控流程 程序版本发布管控由配臵管理组负责～工作流程说明如下: 70 ,1,资料提交环节 1,项目组在执行版本发布前～按要求填写《金税三期XX项目版本审核记录表》,以下简称《版本审核表》,需项目组填写的部分内容和相关的附列资料～需提交的资料主要包括:版本发布计划及人员组织安排,版本发布说明,详细说明版本解决的问题和实现方式、可能的风险及避险措施～涉及的关联应用系统等,,版本源代码程序等,验证测试报告,其它有助于审核的其它资料。 2,《版本审核表》必须在项目组执行版本发布前提交～审核通过后方可执行版本发布, 3,项目组提交的资料不符合审核要求的～应配合配臵管理组及时提交补充资料～直至完成版本审核。 ,2,资料接收环节 1,配臵管理组对项目组提交的《版本审核表》及其附列资料的规范性、完整性进行审核, 2,提交的《版本审核表》和附列资料不符合要求的～配臵管理组应及时反馈至项目组接口人～直至提交的资料符合要求为止, 3,配臵管理组对资料审核通过后～执行版本审核环节。 ,3,版本审核环节 1,配臵管理组会同应用管控组依据项目组提交的资料～从时间安排的合理性、架构层面的符合性等方面进行全面审 71 核, 2,配臵管理组审核完成并填写《版本审核表》相关部分内容后～执行风险评估环节。 ,4,风险评估环节 1,总体组根据版本审核结果～对版本发布可能产生的风险进行全面评估, 2,总体组根据风险评估结果～判断是否执行版本发布,允许发布则通知项目组执行版本发布程序～评估不通过则反馈至项目组接口人, 3,总体组根据风险评估结果～填写《版本审核表》相关部分, 4,版本发布后由上线单位进行验证～如有反馈信息可提交至配臵管理组～由配臵管理组将反馈信息补充至《版本审核表》中并上报总体组。 九、运行维护方案 ,一,适用范围 时间范围:金税三期省级集中系统部署开始～到项目组向运维单位正式交维为止。 适用环境:用户测试、培训、生产等环境。 运行维护对象包括基础设施、系统软件、应用软件等。 运维人员包括国家税务总局、省市国、地税、各软硬件厂商运维人员。 72 在优化实施阶段完成后～金税三期工程系统整体运维将移交至总局电税中心～具体运维工作参见国家税务总局《税务信息系统两级运行维护管理办法》,国税函„2007?368号,～本方案不再赘述。 ,二,运维工作目标 1. 保障优化项目组负责运维工作期间～系统的安全、高效、持续、稳定运行。 2. 保障金税三期省级应用集中模式下业务系统产生的税收数据规范、统一、准确。 3. 保证金税三期省级应用集中后～各省国地税税务业务系统的版本统一。 4. 规范运维服务和职能管理体系～明确各级运维服务角色的职责定位～保证运维服务和管理工作的流程化、规范化和合理化。 ,三,运维工作原则 1. 省级运维为基础～总局运维为依托。 2. 统一服务平台～统一接收反馈。 3. 规范、效率和安全并重。 ,四,运维工作内容 运维工作内容主要包括两类:业务运维和技术运维。 73 图9.1 金税三期优化实施阶段运维工作内容 1. 业务运维 业务运维是指保障各应用系统功能实现业务需求的过程～包括问题解答、业务确认、问题审定、需求变更、业务培训、应急处理等内容。 2. 技术运维 技术运维是指采用相关的技术、制度、流程和文档等～对系统及其运行的软硬件环境,包括设备、存储、网络、软件及服务等,进行维护和监控,系统版本和补丁的管控和发布,对系统前台功能模块不能直接处理的错误数据、垃圾数据～经业务审批后通过后台数据运维的确认、审核以及执行等。 74 ,五,运维组织架构 1. 运维体系结构 在优化实施阶段及上线运行初期～依据“省级运维为基础～总局运维为依托”的运维原则～运行维护体系分为总局优化实施运维组、省级运行维护中心两级。总局优化实施运维组由总局金税三期工程办负责筹建和管理。省级运行维护中心由各省信息中心负责筹建和管理～由信息中心及相关人员组成。为保证运行维护体系的正常运转～各级税务机关应确保运行维护工作所需费用。 省级运维主要从事本省各应用系统的日常运行维护工作。总局优化实施运维组主要指导省级运维工作～面向省级运维提供技术支持。 2. 运维管理模式 在金税三期省级应用集中～全国数据集中的模式下～总局和省局均有应用系统部署～依据“统一服务平台～统一接收反馈” 的运维原则～结合实际情况～运维工作采用“三级服务”管理模式,即一线、二线、三线,～根据问题级别协同完成运维工作～实现运维人员的专业化分工～提高运维服务效率和质量～降低运维服务总体成本。 一线支持除负责IT基础设施的实时监控管理外～主要承担运维服务台职能～负责处理正常级别的服务请求～协调一线、二线、三线IT支持人员～对问题的处理进行有效的 75 跟踪和监控。当最终用户提出请求时～运维服务台作为呼叫受理反馈部门接受服务请求～记录故障报告～解答问题,对不能直接解决的运维请求提交二线支持解决～运维服务台同时进行跟踪和催办。 二线支持负责解决一线处理不了、或解决方案,流程,涉及多部门间的协调、请示、审批的问题。包括一线支持人员不能即时解决的问题、问题库中没有相关案例的疑难问题、处理方案超出“端对端”的范围,如流程改进,的问题、其它一线不能关闭的问题。必要时需协调各税务部门、供应商、开发商等内外部资源解决问题。 三线支持负责将二线无法处理的问题提交给公司高级支持团队～同时针对硬件及系统软件等的故障～要求服务承包商或原厂商依照服务级别协议,SLA,提供支持。 图9.2 金税三期优化实施阶段运维管理模式 76 3. 省局运维架构 根据前述运维体系结构～按照“三级服务”管理模式～提出如下省局运维服务参考架构: 图9.1 金税三期优化实施阶段省局运维架构 ,1,问题,事件,产生。一是用户,税务干部或纳税人,通过电话、邮件或直接登录服务台提交问题～二是监控系统按照预先设臵监控报警规则通过邮件、短信等多种方式向一线支持人员报警～或直接触发服务台自动生成问题工单进入处理流程。用户提交问题时也可直接查看问题库寻找类似问题的解决方案～尽可能缩短问题处理时间。 ,2,一线支持人员通过监控平台等工具或手段～对故障进行快速诊断、定位～并及时处理、解决和关闭～或提交 77 二线处理并进行跟踪和监控。 ,3,二线支持人员通过运维支撑平台及时处理问题。对不能解决的问题～由现场负责人及时联系、协调三线支持人员解决。 ,4,所有问题,事件,及其处理过程、方法和结果均由运维支撑平台记载～并通知一线支持人员或用户进行关闭。 ,5,现场支持人员同时负责问题提报工作流的维护、问题库管理维护、监控报警规则设臵与维护。 ,6,现场支持小组将定期提交工作报告～分析问题～总结经验～提出培训或改进建议。 ,六,运维工作流程 运维流程保障运维服务执行的规范性。本方案给出1个服务台和4个核心流程,变更管理、问题管理、版本管理、测试管理,的设计～各地应结合实际情况在运维工作中调整并落实这些设计。 1. 变更管理流程 变更管理主要负责评估总局和各省局提交的重大配臵变更申请、变更计划制定和变更管控。 具体的变更管理流程如下: ,1,对总局优化实施项目组和省局运维人员提出的重大配臵变更申请,如应用系统网络、存储、主机、中间件、 78 数据库、操作系统的重大配臵调整等,进行评估～综合判断变更的风险、可行性、所需资源等～审定变更方案、计划。 ,2,方案实施后～按计划对变更进行验证和监控。 2. 问题管理流程 问题管理主要负责对项目组、各试点单位在金税工程三期的开发、测试、试运行、推广等过程中搜集、反馈的涉及需求、技术、应用功能等方面的问题实施统一管理～在统一问题管理平台集中分发和处理。 具体的问题管理流程如下: ,1,基层用户和省级监控提交运维请求～由坐席岗受理～坐席岗查询知识库并进行解决～无法解决的提交给乙方现场支持人员,现场支持人员无法解决的录入到“金税工程三期上线保障平台”～转由二线项目组人员分析解决,二线支持人员将处理过程录入到“金税工程三期上线保障平台”～并将解决结果反馈给一线人员～由一线人员将问题关闭。 ,2,如遇紧急问题需要即时解决的～一线人员通过即时通讯工具向二线的项目组寻求直接的支持。事后一线人员需要将相关问题现象录入到“金税工程三期上线保障平台”～二线支持人员事后将处理过程录入到“金税工程三期上线保障平台”～由一线人员将问题关闭。 ,3,如遇省级运维中心无法解决的由省局运维中心将问题通过“上线保障”提交至总局应用管控组。 79 3. 版本管理流程 版本管理主要负责对开发商的软件版本进行管控～包括金税三期工程应用系统、系统软件和工具软件的厂商补丁。整个系统版本由总局统一管理维护～省局运维人员负责将版本发布到各省生产环境～保证版本的稳定性和一致性。 版本管理流程由总局优化实施项目组下的配臵管理组和测试管控组具体制定。 4. 测试管理流程 测试管理主要负责建立测试管理制度～对金税三期工程优化实施建设过程中所涉及的实验室联调测试和用户环境测试进行事前审核、事中监管和事后评估～实现全环节、全生命周期的监管。 测试管理流程见管控方案中测试管控有关流程。 ,七,运维制度建设 为保障系统的安全、高效、持续、稳定运行～顺利完成系统的正式交维～应全面推进运维制度的建立和落实～包括:系统和应用管理制度、安全管理制度、故障管理制度、技术支持工具管理制度、人员管理制度和质量考核制度等。 1. 系统和应用管理制度 包括省级集中工程所有IT环境中的软硬件制定的指标、性能、版本及配臵等技术方面的管理制度。 80 2. 安全管理制度 包括网络、主机、数据库、中间件、应用软件、数据的安全管理制度及安全事故应急处理制度。 3. 故障管理制度 包括故障的监控收集、标准处理流程、分类及响应效率等管理制度。 4. 技术支持工具管理制度 包括对日常运行维护平台、用户问题受理平台,呼叫中心,、故障处理和问题跟踪系统、运行维护知识库、决策分析系统等的使用、维护的有关制度。 5. 人员管理制度 包括对运行维护人员的能级管理制度、奖惩制度、绩效考核制度等。 6. 质量考核制度 对以上各类制度的执行情况进行考核。 十、实施计划 ,一,总体实施计划 金税三期工程省级应用集中优化实施的总体计划如下: 工作阶段 时间 主要工作任务 备注 应用架构优化调整 数据架构优化调整 优化设计开发阶段 4个月 关键技术优化 应用功能优化 内部功能测试 内部实验室测试阶段 3个月 与优化开发并行 内部压力测试 实验室联调测试阶段 1个月 系统集成测试 81 与外部系统的联调测试 系统功能测试 用户验证测试阶段 2个月 系统压力测试 1个月 培训和试点环境准备 与UAT测试并行 试点单位运行阶段 1个月 试点省某市单轨试运行 2个月 单轨试运行 其他两省单轨运行 其他试点单位运行阶段 1个月 新增两省试运行准备 表10.1 金税三期优化实施阶段总体实施计划 里程碑计划如下: 工作阶段3月4月5月6月7月8月9月10月11月12月 优化方案设计开发阶段 内部实验室测试阶段 实验室联调测试阶段 用户验证测试阶段 试点省某市单轨试点单位运行试点省全省单轨 其他两省运行其他两省单轨 新增两省运行试运行准备工作 表10.2 金税三期优化实施阶段总体里程碑计划 ,二,各子系统明细实施计划 1(核心征管系统及应用总集成,中软, 整体计划分为两个阶段。第一个阶段～到三月底～根据二月份广东南海会议结论～交付一个版本～包含涉及的架构调整工作及部分初始化,工作流、岗则权限配臵,优化调整工作。 第二个阶段～预计到六月底～根据二月底明确的三省差异需求及特色系统接入需求～交付一个版本～包含新建系统 82 边界切分新增内容、三省差异需求、三省特色系统接入、查询、用户体验初步优化。 第一阶段明细计划详见下表。其中超出三月底的工作项～属于不影响开发及用户测试的。由于部分工作项输入未明确～第二阶段明细计划暂未列出。 任务大计划开始计划结束任务小项 前臵条件 项 时间 时间 一、技术平台完善 待办事宜集成 2014/3/1 2014/3/31 需要个税配合 需要先明确技 统一流程查询 2014/3/1 2014/3/31 术方案～需要个 税配合 待办事宜页面跳转 2014/3/1 2014/3/3 门户平 台 流程监控增加单流程任务对账链2014/3/1 2014/3/31 需要个税配合 接 提供个人归档任务的查询 2014/3/10 2014/3/15 门户集成关系的梳理 2014/3/15 2014/3/31 双浏览器内核渲染的配合和测试 2014/3/1 2014/3/31 需要数据组和 核心 机关岗位维护 2014/3/1 2014/3/5 征管开发组确 认 需要数据组和权限功核心 机构岗位人员维护 2014/3/15 2014/3/20 能优化 征管开发组确 认 统一初始化口部门权限默认提升一级 2014/3/25 2014/3/31 径 权限信息合并检查 2014/3/15 2014/3/31 权限内部规则梳理 2014/3/15 2014/3/31 服务路由模型优化开发 2014/2/24 2014/3/31 统一制定系统 批量报文交换优化 2014/3/1 2014/3/15 间xml压缩报文 格式和规范 应用集JMS异常处理机制完善 2014/3/15 2014/3/31 成平台 验证熟悉 weblogic的入故障隔离 2014/3/15 2014/4/15 口和出口控制 实现机制 83 JCA对入口出口流量控制完善 2014/4/1 2014/4/30 控制的实现机 制 在路由模型和界面化配臵管理 2014/5/1 2014/6/30 流量控制模型 稳定下开发 基于模型稳定服务监控 2014/7/1 2014/7/31 和配臵管理稳 定下开发 对工作流模型历史版本可以进行2014/3/3 2014/3/10 维护 需要web组提供记忆常用推送人并自动选中 2014/3/1 2014/3/31 接口 推送选人页面支持模糊查询 2014/3/1 2014/3/7 推送绝对级次时含部门 2014/3/1 2014/3/7 对历史已办结或者作废流程定期核心征管提供2014/3/7 2014/3/15 清理 清理条件 BS设计器机关到区县 2014/3/7 2014/3/15 依赖中创提供流程分支作废 2014/3/20 2014/3/31 接口～最晚3月 20前提供 依赖中创提供BS设计器流程图增加描述 2014/3/20 2014/3/31 接口～最晚3月 20前提供 工作流 依赖中创提供根据运行图恢复定义图 2014/3/20 2014/3/31 接口～最晚3月 20前提供 依赖中创提供建模数据库与运行数据库分离的2014/3/20 2014/3/31 接口～最晚3月支持 20前提供 依赖中创提供支持模型规则发版 2014/3/20 2014/3/31 接口～最晚3月 20前提供 配臵规则整合链接分权限 2014/3/15 2014/3/20 流程监控增加触发对账按键 2014/3/15 2014/3/20 支持上级机关对下级机关的流程 规则进行上级机关的全部下级进2014/3/15 2014/3/31 行下发～支持批量～复制与引用 建立流程模板配臵中心 2014/3/1 2014/4/31 结果集最大记录行数默认参数 2014/2/25 2014/3/15 优化核心框架内部基础对象访问核心框2014/2/25 2014/3/15 方式和调用机制 架 提供终止指定会话的机制 2014/3/1 2014/3/20 完善日志组件 2014/3/1 2014/3/31 84 优化内部服务组件 2014/2/25 2014/3/15 提供状态缓存服务组件 2014/3/1 2014/3/31 提供应用级锁管理组件 2014/3/1 2014/3/31 web框架优化～web框架渲染优化2014/3/1 2014/3/5 版分析与重构 web框架优化～web框架渲染优化2014/3/6 2014/3/10 版典型用例性能验证 web框架优化～web框架渲染优化2014/3/11 2014/3/15 版典型用例功能验证 关键用例优化～关键用例优化方2014/3/16 2014/3/31 案梳理 关键用例优化～开发组按照优化2014/3/16 2014/5/30 方案实施～web组全程支持 关键用例优化～用例性能测试 2014/4/1 2014/5/30 关键用例优化～用例功能测试 2014/4/1 2014/5/30 webkit内核插件【chromeframe】 使用方案～插件安装～熟悉基本2014/3/1 2014/3/5 功能、使用方法等 webkit内核插件【chromeframe】 使用方案～技术攻关:ie与webkit2014/3/6 2014/3/15 内核交互 web框架webkit内核插件【chromeframe】优化 使用方案～技术攻关:webkit内2014/3/6 2014/3/15 核下使用activex控件【word打 印和套打】 webkit内核插件【chromeframe】 使用方案～将插件集成到web框2014/3/16 2014/3/20 架中～并封装调用接口事件等 webkit内核插件【chromeframe】 使用方案～与门户组确定内核切2014/3/21 2014/3/31 换标准～并集成,包含应急回退 机制 webkit内核插件【chromeframe】 使用方案～操作系统、浏览器版2014/4/1 2014/4/15 本兼容性测试～并解决相关问题 webkit内核插件【chromeframe】 使用方案～金三系统兼容性测试～2014/4/16 2014/5/31 并解决相关问题 其它系统兼容性测试～并解决相2014/5/1 2014/5/31 关问题 二、总局参与、跨省、跨国地税业务功能改造及系统边界变动驱动的任务 ,一,登记、认定、优惠及证明域 边界切税收减免备案 2014/3/1 2014/3/15 分 85 单位纳税人登记 2014/3/15 2014/3/30 个体经营登记 2014/3/15 2014/3/30 临时税务登记 2014/3/15 2014/3/30 跨省、跨跨省、跨国地税组织变更登记 2014/3/15 2014/3/30 国地税技术实现方案业务修汇总,合并,纳税企业信息备案: 2014/3/15 2014/3/30 评审通过 改 税收调查企业认定查询修改 2014/3/15 2014/3/30 注销税务登记修改。 2014/3/15 2014/3/30 税收减免备案 2014/3/15 2014/3/30 自然人查询逻辑修改 2014/3/15 2014/3/30 接口修自然人间接登记逻辑修改 2014/3/15 2014/3/30 改 自然人批量业务接口修改 2014/3/15 2014/3/30 ,二,征收域 跨省、国定期定额核定 2014/3/15 2014/3/30 地税业非居民欠税追缴 2014/3/15 2014/3/30 务 系统边税收计划 2014/3/15 2014/3/30 界切分 会计审核公式 2014/3/10 2014/3/30 ,三,发票域 发票计划 2014/3/1 2014/3/31 跨省、跨发票计划调整 2014/3/1 2014/3/31 国地税增值税抵扣凭证抵扣申请 2014/3/1 2014/3/31 业务改代开增值税专用发票 2014/3/1 2014/3/31 造 代开货物运输业增值税专用发票 2014/3/1 2014/3/31 ,四,申报域 白酒消费税最低计税价格核定 2014/2/21 2014/3/15 卷烟消费税计税价格核定管理 2014/2/21 2014/3/15 车价信息管理 2014/2/21 2014/3/15 车辆合格证电子信息重复使用 2014/2/21 2014/3/15 居民企业,查账征收,企业所得2014/2/21 2014/3/15 税月,季,度申报-跨省总分机构 居民企业,查账征收,企业所得2014/2/21 2014/3/15 税月,季,度申报-跨省报验登记 跨省及居民企业,查账征收,企业所得2014/2/21 2014/3/15 跨国地税年度申报-跨省总分机构 税 居民企业,查账征收,企业所得2014/3/15 2014/3/31 税年度申报-跨省报验登记 增值税一般纳税人申报-跨省总2014/3/15 2014/3/31 分机构 车辆购臵税申报-最低计税价格 2014/3/15 2014/3/31 车辆购臵税申报-跨省申报、退税 2014/3/15 2014/3/31 关联业务往来年度报告申报-关2014/3/15 2014/3/31 联方跨省 确定受控外国企业-股东信息跨2014/3/15 2014/3/31 86 省 通用申报,税及附征税费,-地税2014/3/15 2014/3/31 代征国税附税 企业所得税申报-特定减免 2014/3/15 2014/3/31 增值税、营业税、附加税-特定减2014/3/15 2014/3/31 免 边界切扣缴储蓄存款利息所得个人所得2014/2/21 2014/3/31 分 税申报 接口修外部数据-合格证电子数据相关2014/2/21 2014/3/31 改 接口 ,四,风险处理相关域 具体集成方案～单边预约定价预备会谈 2014/3/3 2014/3/28 修改方案评审 通过 具体集成方案～双边或多边预约定价预备会谈 2014/3/3 2014/3/28 修改方案评审 通过 具体集成方案～正式申请 2014/4/1 2014/4/30 修改方案评审 通过 具体集成方案～审核评估 2014/4/1 2014/4/30 修改方案评审 通过 具体集成方案～磋商,会谈, 2014/4/1 2014/4/30 修改方案评审 通过 跨省及具体集成方案～ 跨国地签订单边预约定价安排 2014/4/1 2014/4/30 修改方案评审 税业务 通过 具体集成方案～签订双边或多边预约定价安排 2014/4/1 2014/4/30 修改方案评审 通过 具体集成方案～接收税收情报管理 2014/5/1 2014/5/30 修改方案评审 通过 具体集成方案～税收情报提供 2014/5/1 2014/5/30 修改方案评审 通过 具体集成方案～税收情报请求 2014/5/1 2014/5/30 修改方案评审 通过 具体集成方案～特别纳税调查立案 2014/5/1 2014/5/30 修改方案评审 通过 87 具体集成方案～特别纳税调查结案 2014/5/1 2014/5/30 修改方案评审 通过 具体集成方案～专家会审 2014/5/1 2014/5/30 修改方案评审 通过 从总局获取单 据号服务可使稽查案件督办管理 2014/5/1 2014/5/30 用,具体集成方 案～修改方案评 审通过 具体集成方案～ 2014/5/1 2014/5/30 修改方案评审缔约国方提请相互协商申请 通过 具体集成方案～ 2014/5/1 2014/5/30 修改方案评审特别纳税调查跟踪管理 通过 委托协查\特别纳税调整发函\非 居民企业所得税汇算清缴发函\ 非居民承包工程作业和提供劳务跨省服务调用项目信息传递发函\出口退税发2014/3/3 2014/3/28 通道能正常通函\税收情报交换管理发函\出口信 退税催办发函\税收情报交换管 理发函 出口退税发函收函、委托协查收 函、特别纳税调整发函收函、税 收情报交换管理发函收函、非居 民企业所得税汇算清缴发函收 函、非居民企业所得税源泉扣缴 管理发函收函、非居民承包工程 作业和提供劳务项目信息传递收跨省服务调用函、出口退税催办发函收函、出2014/4/1 2014/4/30 通道能正常通口退税复函收函、受托协查复函信 收函、特别纳税调整复函收函、 税收情报交换管理复函收函、非 居民企业所得税汇算清缴复函收 函、出口退税延期复函收函、受 托协查延期复函收函、特别纳税 调整协查延期复函收函 受托协查复函\特别纳税调整复 函\非居民企业所得税汇算清缴跨省服务调用复函\出口退税复函\税收情报交2014/5/1 2014/5/30 通道能正常通换管理复函\出口退税延期复函\信 受托协查延期复函\特别纳税调 88 整协查延期复函\受托协查延期 复函\特别纳税调整协查延期复 函 跨国地税服务 纳税信用等级评定 2014/3/3 2014/3/28 调用通道正常 通信 ,五,综合优化类 后台启动流程的也要支持可以选需要和业务组2014/6/1 2014/6/30 人 沟通确定输入 流程配 臵规范 一步的流程统一切换到即办型功2014/5/1 2014/6/30 能 三、数据架构调整 数据架确定数据架构具体调整总体方案 2014/2/24 2014/2/28 构及数数据分发专题设计 2014/3/1 2014/3/31 据集成数据集成方案调整 2014/3/1 2014/3/30 调整 代码表版本管理流程制定 2014/2/26 2014/3/7 主数据 取消后权限和工作流模型数据的复制及2014/2/26 2014/3/7 系统相版本控制方案制定 关的调原采用主数据同步策略的系统间2014/3/1 2014/3/7 整 数据交换策略梳理调整 四、实验室联调及版本基线形成 实验室 联调测核心征管系统回归联调测试 2014/3/17 2014/3/31 试 版本形用户可测试的省级应用集中版本 2014/3/31 成 提交 表10.3 核心征管系统和应用总集成实施计划 2(个人税收管理系统,税友, 计划开始计划结束任务大项 任务小项 前臵条件 时间 时间 一、需求分析 业务切分后后的需求基线2014/2/22014/2/2 版本 1 8 需求基线 2014/2/22014/2/2各省差异需求基线 1 8 2014/3/1业务组提供需根据需求整理疑问 2014/3/1 0 求基线 需求澄清 2014/3/12014/3/1需求澄清 1 4 89 2014/3/12014/3/2个税提交关联关系报告 5 0 系统间关2014/3/22014/3/2个税提交关联核心征管确认关联关系 联关系 1 2 关系报告 核心征管提供接口(含2014/3/22014/3/2核心征管确认 XSD) 3 8 关联关系 2014/3/12014/3/2需求分析编写 需求澄清 5 3 2014/3/22014/3/3需求分析编写需求分析 需求分析成果确认 4 1 完成 用户反馈确认需求分析调整 2014/4/1 2014/4/5 结果 二、概要设计 2014/2/22014/2/2确认集成规范 3 8 需要总集成改2014/3/1IA集成 2014/3/1 造完成并提供0 应用规范 集成设计 需要总集成改2014/3/1应用间服务接口集成 2014/3/1 造完成并提供0 应用规范 需要总集成改建模工具易用性改造及发2014/3/12014/3/1 造完成并提供布功能改造 0 应用规范 应用合并的设计 2014/3/3 2014/3/5 单据号的全局性唯一性设应用架构2014/3/3 2014/3/5 计 设计 工作流事务一致性设计 2014/3/3 2014/3/5 2014/2/22014/2/2取消数据同步设计 3 8 并库后调整设计 2014/3/1 2014/3/5 数据架构2014/2/22014/2/2设计 数据模型调整设计 3 8 自然人数据库的数据模型2014/3/12014/3/1 设计 0 技术架构源码工程调整设计、框架2014/2/22014/2/2 设计 改造设计 5 8 关键内容2014/2/2自然人建档流程等设计 2014/3/5 设计 5 架构管控2014/3/2提交概要设计确认 2014/4/1 确认 9 三、详细设计与编码 源码工程调整源码包结构 2014/2/22014/3/2 90 改造 8 集成与回归测试 2014/3/3 2014/3/7 2014/3/1流程与物理数据模型设计 2014/3/7 新增凭证5 结构化模2014/3/12014/3/3块 编码与单元测试 5 0 流程与物理数据模型设计 2014/4/1 2014/4/5 现有模块 2014/4/1改造 编码与单元测试 2014/4/6 2 新增模块2014/4/1流程与物理数据模型设计 2014/4/6 开发 5 2014/4/12014/4/3 编码与单元测试 6 0 数据同步总集成编码完2014/4/3取消后相设计编码与单元测试 2014/4/1 成相应服务接0 关改造 口 全国集中2014/6/1版模块改全国集中版模块改造 2014/6/1 0 造 四、系统测试 测试环境准备 2014/5/1 2014/5/3 2014/4/12014/4/2测试用例编写 详细设计完成 测试准备 5 7 2014/4/22014/4/3测试用例编写测试用例评审 8 0 完成 2014/5/1第一轮功能测试 2014/5/4 开发完成 3 2014/5/12014/5/1第一轮测试完第一轮功能回归测试 4 9 毕 2014/5/22014/5/2第一轮测试完第二轮功能测试 0 5 毕 2014/5/22014/5/2系统测试 第二轮功能回归测试 6 9 2014/5/12014/5/2第一轮功能测第一轮性能测试 4 3 试完毕 2014/5/22014/5/2第一轮性能测第二轮性能测试 4 9 试完毕 2014/5/32014/5/3功能测试及性测试报告 0 1 能测试完毕 五、实验室联调测试 实验室联调申请 2014/6/1 2014/6/2 系统测试完成 联调准备 实验室环境搭建 2014/6/2 2014/6/6 联调申请通过 业务场景测试用例 2014/6/1 2014/6/6 详细设计完成 91 2014/6/1连通性测试 2014/6/7 环境搭建完毕 5 2014/6/12014/6/2连通性测试通联调 业务场景测试 6 3 过 2014/6/22014/6/2业务场景测试联调报告确认 4 4 通过 六、成果提交 提供用户2014/6/22014/6/3实验室联调测软件成果 测试成果 5 0 试通过 七、用户测试 2014/6/2硬件环境 2014/6/1 2 2014/6/2环境准备 办公环境 2014/6/1 2 2014/6/22014/6/3硬件环境准备软件部署 7 0 完毕 用户培训 用户培训 2014/7/1 2014/7/5 环境准备完成 用户测试 用户测试 2014/7/6 ,,,, 用户培训完成 表10.4 个人税收管理系统实施计划 3(管理决策1包,神码, 计划开始计划结束工作事项 时间 时间 一、数据架构调整 1.1技术方案确定 设计方案 关于薪酬设计方案通用技术作品设计方案停车场设计方案多媒体教室设计方案农贸市场设计方案 编写 2014-3-1 2014-3-21 设计方案内部评审 2014-3-22 2014-3-31 1.2 数据集成平台插件开发 2014-4-1 201405-15 1.3内部测试及实施验证 2014-5-16 2014-6-30 二、业务部分 2.1 税收核算优化 优化方案确定 设计方案编写 2014-3-1 2014-3-18 设计方案内部评审 2014-3-22 2014-3-31 编码开发 统一视图涉及核算数据,税费信息等,2014-4-1 2014-4-30 设计优化 税费信息等抽取,ETL,处理优化 2014-4-1 2014-4-30 核算数据加工处理调整 2014-4-1 2014-4-30 内部测试及验证 2014-5-1 2014-5-30 92 2.2 结构化申报表统一视图ETL开发,需核心 征管XML结构化开发完成后, 获得生产系统数据模型 2014-4-15 2014-4-30 统一视图适应性验证 2014-5-1 2014-5-31 统一视图抽取程序调整 2014-6-1 2014-6-15 统一视图抽取验证及内部测试 2014-6-16 2014-6-30 2.3 业务边界切分确认的业务调整 需求分析 2014-3-1 2014-3-7 详细设计 2014-3-8 2014-3-14 编码开发 2014-3-15 2014-4-30 内部测试及验证 2014-5-1 2014-5-31 实验室联调测试 2014-6-1 2014-6-15 版本发布 2014-6-16 2014-6-16 表10.5 管理决策1包实施计划 4(管理决策2包,税友, 计划开始计划结束任务大项 任务小项 前臵条件 时间 时间 金税三期省核心征管和纳服级集中调整 2014/2/10 2014/2/28 系统省级部署调方案制定 整方案确定 待明确的业 务点与业务 2014/2/24 2014/2/28 组确认 明确本次架构调 调整需要进行跨层整后风险管理系 级数据交换的数据统与核心征管系2014/3/15 2014/4/15 ,与核心征管的关统在业务上有哪 联关系, 些数据需要跨层 级共享 数据流向调明确本次架构调 整 调整需要进行跨层整后风险管理系 级数据交换的数据统与纳服系统在2014/3/15 2014/4/15 ,与纳服的关联关业务上有哪些数 系, 据需要跨层级共 享 数据流向调整代码2014/4/8 2014/4/15 内部评审 测试用例编写 2014/4/1 2014/4/7 系统测试 测试用例内部评审2014/4/8 2014/4/15 与修改 93 系统测试环境准备 2014/4/12 2014/4/15 系统测试,与核心代码层面调整完2014/4/16 2014/4/30 征管的关联关系, 成 系统测试,与纳服代码层面调整完2014/4/16 2014/4/30 的关联关系, 成 联调测试环境准备 待定 待定 与核心征管联调测双方系统测试完待定 2014/6/30 联调测试 试 成 双方系统测试完与纳服联调测试 待定 2014/6/30 成 提交用户测用户测试 待定 待定 联调测试完成 试 表10.6 管理决策2包实施计划 5(纳税服务系统,方欣, 序关键工作任务 完成时间 责任方 备注 号 一、准备阶段 后续大量修改工作都提供省局查询库数2月22日—核心征管、个依赖于查询库～因此1 据字典和建表脚本 —2月28日 税、网络发票 需尽快拿到查询库的 数据字典。 按照现在省局解耦的梳理需提供涉税业2月22日—方案～确认哪些业务2 纳税服务 务服务接口清单 —2月28日 还必须以服务接口的 形式提供。 梳理需优化涉税业2月22日—对于保留的服务接口3 纳税服务 务服务接口清单 —2月28日 提出优化的要求。 纳税服务、安对于省局互联网区域全总集成、安2月22日—安全策略和统一身份4 安全架构问题确认 全策略2包、—2月28日 认证系统相关问题进身份认证项行确认。 目 二、设计阶段 纳税服务、应 用总集成、核 应用架构、部署架心征管、个根据总体组最终确定3月1日——1 构、数据架构、集税、网络发的架构对各个环节的3月12日 成架构细化设计。 票、决策1设计进行细化。 包、决策2 包 94 该项任务的输入为纳优化应用服务接口3月1日——核心征管、个服项目组在2月底之2 设计 3月12日 税、网络发票 前梳理的待优化的接 口清单。 涉税业务功能解耦3月1日——3 详细设计,基于查纳税服务 3月12日 询库, 省局互联网安全架3月1日——安全总集成、4 构设计调整 3月12日 纳税服务 纳税服务、身省局互联网统一身3月1日——份认证项目、5 份认证集成设计调 3月12日 安全策略2整 包 总体组、各相3月13日—6 设计方案评审 关职能组、各 —3月15日 相关项目组 三、开发阶段 后端业务系统优化包括应用集成平台和3月16日—核心征管、个1 应用服务接口开发加载在其上的接口的—4月15日 税、网络发票 实现 实现。 后端决策分析系统3月16日—决策1包、决主要涉及到省局反馈2 调整数据接口实现 —4月15日 策2包 区的调整。 需要相关后端业务系涉税业务功能解耦纳税服务、核3月16日—统项目组提供支持～3 开发实现,基于查心征管、个—4月15日 对查询库结构进行解询库, 税、网络发票 释说明。 将原有查询决策1包一户式查询功能调3月16日—4 纳税服务 数据库的查询～改成整,基于查询库, —4月15日 查询省局查询库。 按照省局部署模式对纳税服务、应自有业务和纳服支3月16日—这部分功能进行修5 用总集成、中撑功能调整实现 —4月15日 改。包括跟局端统一创 权限、工作流的调整。 互联网统一身份认3月16日—纳税服务、身6 证管理调整实现 —4月15日 份认证项目 四、实验室联调阶段 应用总集成、 纳税服务、核 心征管、个实验室联调环境部4月13日—1 税、网络发 署 —4月15日 票、决策1 包、决策2 包、身份认证 2 涉税业务实验室联4月16日—纳税服务、应 95 调测试 —5月15日 用总集成、核 心征管、个 税、网络发 票、决策1 包、决策2 包 纳税服务、应主要包括省局统一权自有业务和纳服支4月16日—3 用总集成、中限和工作流的联调测撑实验室联调测试 —5月15日 创 试。 互联网统一身份认4月16日—纳税服务、身4 证实验室联调测试 —5月15日 份认证 五、测试阶段 应用总集成、 纳税服务、核 心征管、个5月16日—1 测试环境部署 税、网络发 —5月20日 票、决策1 包、决策2 包、身份认证 5月21日—2 测试执行 同上 —6月25日 6月26日—3 双轨运行版本发布 同上 —6月30日 表10.7 纳税服务系统实施计划 6(外部信息交换系统,神码, 任务类别 工作内容 责任人 完成时间 建立设计调整领导工作组 金三工程办 设计调整确定各项工作责任人 金三工程办 领导小组系统上线过程中各项协调2014/3/1 金三工程办 工作 工作 确定设计调整方案 金三工程办 金三外部交换项确认技术方案的可行性 2014/2/25 目组 制定调整明确外部信息交换数据的金三外部交换项2014/2/26 设计方案 清分内容和范围 目组 评审调整方案 金三工程办 2014/3/1 确定调整方案 金三工程办 金三外部交换项需求分析 梳理、优化需求 2014/4/15 目组 96 金三外部交换项分析清分范围及规则 2014/3/15 目组 金三外部交换项编写需求分析文档 2014/5/15 目组 金三外部交换项评审需求分析文档 2014/5/23 目组 金三外部交换项评审清分规则 2014/3/21 目组 金三外部交换项梳理、优化概要设计 2014/5/5 目组 金三外部交换项概要设计 编写概要设计 2014/5/30 目组 金三外部交换项评审概要设计 2014/6/6 目组 金三外部交换项开发 2014/4/6 目组 开发测试 金三外部交换项单元测试 2014/6/30 目组 金三外部交换项 目组 实验室联调测试 金三个税项目组 实验室测金三核心征管项2014/7/31 试 目组 金三外部交换项测试报告 目组 全功能联调 甲方 用户测试 2014/9/30 测试报告 甲方 表10.8 外部信息交换系统实施计划 7(工作流产品,中创, 优先任务描述 计划完成时间 级 2014年3月24跨系统的批量流程同步支持版本控制功能。 高 日 2014年3月24流程作废分支条件查询接口。 高 日 流程分支变量按照系统、业务分类、流程分类区分2014年3月31中 功能。 日 2014年3月31BS设计器增加默认描述支持流程图反向查找功能。 低 日 提供工作流引擎以及数据库实例在各环境下的参中 2014年3月31 97 数建议手册。 日 配合中软时间历史库分离策略 低 点待定 配合中软、各厂商完成性能测试等工作 低 时间待定 2014年3月31用户体验类问题 低 日 表10.9 工作流产品实施计划 98