政务服务预约叫号评价系统建设方案.docx
- 文档编号:25453459
- 上传时间:2023-06-08
- 格式:DOCX
- 页数:48
- 大小:1.15MB
政务服务预约叫号评价系统建设方案.docx
《政务服务预约叫号评价系统建设方案.docx》由会员分享,可在线阅读,更多相关《政务服务预约叫号评价系统建设方案.docx(48页珍藏版)》请在冰豆网上搜索。
政务服务预约叫号评价系统建设方案
政务服务预约叫号评价系统
建设方案
2020年12月
1.项目概述
1.1.项目名称
项目名称:
政务服务预约叫号评价系统
1.2.项目背景
2017年12月,国办政府信息与政务公开办公室发布了《全国综合性实体政务大厅普查报告》,该报告摸清了实体政务大厅在全国的布局和覆盖情况,以及各地政务大厅的创建模式、管理体制、运行机制、服务方式、创新举措和保障制度,并分析了政务大厅在新时期面临的问题和挑战,其中就包括大厅配套服务(如预约、取号、评价)不完善、不到位等问题。
2018年6月,国务院办公厅印发的《国务院办公厅关于印发进一步深化“互联网+政务服务”推进政务服务“一网、一门、一次”改革实施方案的通知》(国办发〔2018〕45号)提出,以集成提效能,推进线下“只进一扇门”。
依托网上政务服务平台,实时汇入网上申报、排队预约、现场排队叫号、服务评价、事项受理、审批(审查)结果和审批证照等信息,实现线上线下功能互补、无缝衔接、全过程留痕,为企业和群众办事线下“只进一扇门”提供有力支撑。
本次项目将针对现有的政务服务发展现状,参考网上政务服务和大厅审批系统的建设与推广模式,以全区统一为建设原则,面向全区区级专业大厅、镇街政务中心、村居党群服务点实现统一规划、统一设计、统一实施,打造全区预约、叫号、取号到评价的全流程一体化服务。
贯彻落实政策要求,通过建设统一的预约系统、排队叫号系统、评价系统,构建“预约-取号-办理-评价”业务、数据一体化平台,促进系统集成、数据共享、业务协同,解决预约、取号、评价之间的数据联动和业务联动问题,推进线上线下集成融合,实现网上预约、线下取号,窗口办理、多渠道评价,服务过程无缝衔接、全过程留痕,切实提高政务服务效率和群众办事服务体验。
1.3.建设依据
本项目软件系统设计和建设严格遵循国家及地方标准规范,以及工信部相关的规范与标准,具体如下:
网络标准:
IEEE802.3,IEEE802.3u,IEEE802.3ab,ANSI/IEEE802.3N,IEEE802.3x,IEEE802.3af,IEEE802.3az,IEEE802.11b/g
1)《信息安全等级保护管理办法》(公通字〔2007〕43号)
2)《信息系统安全等级保护测评要求》GB/T28448GB/T28448—20122012
3)《市政务数据管理暂行办法》(政府令第329号)
4)《市政府投资政务信息化项目管理办法(征求意见稿)》
5)《国家信息化领导小组关于我国电子政务建设的指导意见》(2004年8月5日签发)
6)《电子政务工程技术指南》(2003年1月3日签发)
7)《政务信息资源交换体系》(GB/T21062-2007)
8)《电子政务系统总体设计要求》(GB/T21064-2007)
9)《电子政务标准化指南》,国家标准化管理委员会、国务院信息化工作办公室(2002年5月)
10)《涉及国家秘密的信息系统分级保护管理办法》(国保发〔2005〕16号)
11)《电子信息系统机房设计规范》(GB50174-2008)
12)《计算机软件开发规范》(GB8566-88)
13)《计算机软件产品开发文件编制指南》(GB8567-88)
14)《软件工程术语》(GB/T11457—89)
15)《计算机软件配置管理计划规范》(GB/T12260-90)
16)《计算机软件质量保证计划规范》(GB/T12504-90)
17)《计算机软件需求说明编制指南》(GB9385-88)
18)《计算机软件测试文件编制指南》(GB9386-88)
19)《软件维护指南》(GB/T14079-93)
20)《计算机软件可靠性和可维护性管理》(GB/T14394-93)
1.4.建设内容
本项目建设期为1年。
本次项目建设内容包括:
1.预约叫号评价系统软件开发、云部署、初始化配置;
2.接口标准制定、接口开发、业务整合与数据对接,配合区级业务系统对接联调;
3.区、镇街各业务大厅的推广实施;
4.系统培训、业务操作培训、后台管理培训;
5.运维管理。
2.需求分析
开发满足市区约七百个大厅、三千个窗口部署需要的预约叫号评价系统,基于政务云平台完成云部署,完成区级专业大厅和镇街政务服务中心的部署;制定符合国家、省、市标准的区级预约、叫取号、评价的数据标准和数据交换接口,实现网上预约、排队叫号、业务评价数据和业务办理数据互联互通,解决目前各部门、各镇街的预约、叫号和评价系统标准不统一、接口无法兼容、数据无法交互汇聚等问题;预约叫号评价系统打通与在用的一窗综合受理审批系统,实现业务联通和数据联通;在各专业大厅和镇街政务服务中心完成部署实施和业务培训,保障各个大厅正常运转;运维服务器内保证系统安全稳定运行,支撑全区政务服务体系运转;满足区内各类业务系统的对接需要。
本项目建设内容由政数局按统一标准建设,基于政务云进行集中部署,各镇街和各专业大厅采取统一网络访问的形式使用。
设计过程中应充分考虑网络故障导致的系统无法使用等情形,保证即使网络发生故障,亦能在大厅范围内实现取号、评价,并在网络恢复后上传相关数据。
2.1.系统现状
综合受理系统:
系统负责承接大厅各类业务的统一收件登记,并汇总分发审批系统,然后接收审批系统反馈的审批结果数据,再进行统一出件,即支持“前台综合受理,后台分类审批,窗口统一出件”的模式,并支持出件箱管理服务。
具体功能包括网上业务预审、材料审核和业务受理、材料补正、不予受理、收费管理、业务出件、跨地区/城市收件功能、联合受理业务、批量办理、业务提醒督办、业务统计与导出等。
该系统为(区+镇街)各政务服务中心窗口所使用的统一受理系统。
一窗网上申办系统(包含一体化预约服务系统):
系统负责承接市民的网上申办业务,按照政务服务门户制定的统一建设规范,完成统一的网上申办入口,并已对接综合受理系统以及对接其他部门业务审批系统,为区内其他服务平台,如自助终端、一表单系统、手机微信公众号等提供支撑服务。
具体功能包括身份核验、互联网+可信身份认证、在线填表、材料上传、历史办件复用、办件提交、EMS预约、回执打印、办件进度查询、在线补齐补正、反馈意见查询、网上预约等。
该系统为(区+镇街)各政务服务中心统一的网上入口。
微信小程序:
以微信小程序为渠道和支撑基础,已实现统一身份管理、人脸识别、办件预申办、办件进度查询、业务预约、取号、排队、叫号和评价等功能,同时需要与本次项目对接的标准对接接口已预留。
该程序目前已立项在建。
大数据平台:
能够采集、清洗和分析相关各类数据,按照要求制定各类数据模型。
本次项目的系统中所产生排队数据、评价数据及一体化预约数据都需要推送至该平台。
2.2.网络现状
政务外网网络整体架构如上图所示。
从网络架构上看由:
区府网络平台、政务云平台、互联网、市政务外网出口,以及覆盖全区的接入网络构成,其中区府网络平台由区府办公大楼网、区分政务和会议中心网络及无线覆盖来构成;区政数局核心机房则承载了区的电子政务核心业务平台;而全区的接入网络则通过13个汇聚节点汇聚全区各分支节点,并统一接入到区政数局政务外网核心上。
从整体网络架构上看:
整个网络采用了核心、汇聚、接入的三层逻辑网络架构。
现有整个政务网通过一张物理网络承载了电子政务网络业务。
整个网络基于自建的光纤网络基础平台,网络带宽采用了百兆接入,千兆汇聚,万兆骨干。
从网络技术基础角度看,整个网络采用了以太网交换机为技术基础进行构建。
既具备交换机构建网络,在运维层面简单,接口标准的特点,也继承了以太网交换网络所具有的缺点。
如:
L2网络广播、网络病毒泛洪等管理难度大的特点。
本次建设系统所需部署的地点,均已接入政务外网网络。
3.总体设计方案
3.1.总体目标
采用信息化手段,通过计算机应用软件、3G/4G无线网络技术建设政务服务预约叫号评价系统。
结合政务服务发展现状,延续全区统建一窗网上申办及综合受理审批系统的建设思路,面向区、镇街、村居三级采取统一规划、统一设计、统一实施的思路,构建区、镇街、村居三级统一预约-叫号-取号-评价体系,开发一套软件并率先在区和镇街两级进行实施。
主要完成以下内容:
序号
采购内容
数量
单位
1
软件开发
预约管理功能模块
1
套
2
排队叫取号功能模块
1
套
3
评价管理功能模块
1
套
4
运营管理模块
5
系统管理模块
1
套
6
业务整合
与“好差评”系统对接
1
套
7
与一窗网上申办及综合受理审批系统对接
8
与大数据云平台数据对接
1
套
9
与政务微信小程序数据对接
1
套
10
与硬件设备的对接
1
套
3.2.设计原则
3.2.1.标准化原则
系统建设充分考虑房管工作的现状,满足房管工作的程序化、规范化要求。
系统建设过程中对房管管理流程进行规范统一,形成本项目的标准规范,结合国家已有的相关标准和技术规范,指导本项目系统设计与应用。
3.2.2.稳定性原则
系统采用成熟和高度商品化的开发平台以及公司多年的技术成果,在系统设计阶段就充分考虑系统的稳定,采用科学的有效的设计方案进行设计。
另外,在系统开发有特定的流程和规范,比如系统开发流程规范,代码编写规范,测试规范,质量保证计划等,系统开发过程中按照已有的规范进行,确保系统的质量。
3.2.3.安全性原则
系统的安全性是用户特别关心的事情,也是系统设计的根本。
系统的安全包括三个方面的内容:
物理安全,逻辑安全和安全管理。
物理安全是系统设备及相关设施受到安全保护,避免破坏和丢失。
安全管理包括各种安全政策和机制,逻辑安全是指系统中的信息安全,主要分为保密性,完整性和可用性。
系统在设计阶段充分考虑信息安全,包括各种安全验证,数据存储的安全,敏感信息的加密,数据传输中的加密,数据访问的验证等确保了系统运行的安全性。
通过各种安全技术手段,保障系统运行的安全。
遵守现行的各项保密制度和规定,尚未公开或不宜公开的数据与信息采取严格的安全保护措施。
用户的商业秘密不得开放给XX的用户。
系统外部安全:
系统的安全性充分考虑网络的高级别、多层次的安全防护措施,包括备份系统、防火墙和权限设置等措施,保证政府部门的数据安全和政府机密;同时考虑系统出现故障时的软硬件恢复等急救措施,以保障网络安全性和处理机安全性。
系统要形成相对独立的安全机制,有效防止系统外部的非法访问。
系统内部安全:
在保证系统外部安全的同时,系统也能确保授权用户的合法使用。
系统本身具有容错功能,包括出错提示、原因,并能自动或通过人工操作,使出错的系统恢复到正常状态。
系统还提供严格的操作控制和存取控制。
系统运行安全:
在逻辑上,系统具有抵御对系统的非法入侵的能力;在物理上,系统保证不存在可能的单点故障,提供资源数据的备份能力。
系统支持定期的自动数据备份和手工进行数据备份,能够在数据毁坏、丢失等情况下将备份数据倒回,实现一定的数据恢复。
3.2.4.先进性原则
在系统总体设计上,借鉴国内己有的相关经验。
在技术上,采用国际上先进、成熟的技术,使得设计更加合理、先进。
在注重系统实用性的前提下,尽可能采用先进的计算机软、硬件环境;在软件开发思想上,严格按照软件工程的标准和面向对象的理论来设计,保证系统的先进性。
3.2.5.易用性原则
易操作性是指用户操作和运行控制软件的难易程度的软件属性。
该特征要求软件的人机界面友好、界面设计科学合理以及操作简单等。
易操作的软件让用户可以直接根据窗口提示上手使用,无需过多的参考使用说明书和参加培训;
各项功能流程设计的很直接,争取在一个窗口完成一套操作;
在一个业务功能中可以关联了解其相关的业务数据,具有层次感;
合理的默认值和可选的预先设定,避免了过多的手工操作;
如果软件某操作将产生严重后果,该功能执行是可逆的,或者程序给出该后果的明显警告并且在执行该命令前要求确认;
如果一旦出现操作失败,及时的信息反馈是非常重要的,没有处理结果或者是处理过程的信息反馈不是一个好系统;
流畅自然的操作感觉,来源于每一次操作都是最合理的。
在页面和流程上浪费用户的鼠标点击,也是在挥霍用户对于软件的好感。
清晰、统一的导航要贯穿系统的始终;操作按扭、快捷键等遵循一致的规范、标准是必须的,不要给操作者额外记忆的负担。
3.2.6.可扩展性原则
系统的扩展性是测量系统设计好坏的一个重要的标准,良好的扩展性可以使系统有健壮的生命力,也为系统的升级和将来的维护打下良好的基础。
系统在需求调研阶段就充分考虑用户的用途以及将来的发展方向,在概要设计阶段充分考虑系统的使用和发展,为系统的可扩展性提供重要保障。
采用面向对象、面向服务的设计思想,按不同的网络、不同的功能、不同的职能划分成各种功能组件,各功能组件既可以独立形成系统又可以组成一个综合系统,方便实现从子系统到综合系统,从综合系统到独立系统的升级过渡,保护用户的投资。
良好的扩充性和可维护性,实现在快速搭建总体框架的基础上分业务,分任务的逐渐充实整个系统,使系统具备可持续升级的基础。
功能扩展:
为了满足用户今后系统扩容和扩大应用范围的需求,系统充分考虑从系统结构、功能设计、管理对象等各方面的功能扩展。
软硬件升级:
系统充分考虑软硬件平台的可扩展性及软、硬件的负载平衡机制。
随着关键软件和硬件的发展以及管理功能的增加,系统具有灵活和平滑的扩展能力。
关键软件和硬件的发展以及管理功能的增加,系统具有灵活和平滑的扩展能力。
3.2.7.可维护性原则
可维护性是在软件交付使用后进行的修改,修改之前必须理解待修改的对象,修改之后进行测试,以保证所做的修改是正确的。
系统在设计时充分考虑可维护,尽量做到系统在尽可能少的维护动作下,完成系统功能修改。
在系统功能文档中做到完全的解释,使用户在理解功能时轻松完成系统的维护。
3.3.总体架构
系统主要由“1个规范、1个数据库、1个系统”构成。
“一个规范”即数据标准规范,根据城市管理治理要求,基于国家、省、市相关技术标准规范编制一套适应城市管理建设要求和实际情况的标准规范体系。
;
“一个数据库”即“城市房源管理信息资源库”,作为整个项目的基础数据支撑;
“一个系统”面向公众服务,实现政务服务预约叫号及评价系统。
总体架构主要包括感知层、网络层、数据层、服务层、平台层、应用层、政策法规、安全标准等层面。
项目建设基于信息标准,实现信息数据的集中部署,要做到以下五个方面的统一:
●统一数据标准(数据系统架构、数据库结构、数据表);
●统一基础信息(文字、图片、音视频、虚拟素材等);
●统一地理信息(位置信息、GPS数据、电子地图);
●统一交换接口(内部数据交换接口规范、开放数据接口规范);
●统一技术平台(硬件、软件、网络、安全)。
感知层:
通过各类数据采集和感知技术,如:
RFID、条形码、传感器、摄像头等,实现数据采集和存储,为整个系统治理应用体系提供基础数据的支撑;
网络层:
构建应用级物联、感知、互联、通信、卫星网络,为数据信息的传输流通起到支撑作用;
数据层:
建立以基础地理信息服务、基础设施服务为一体的空间数据服务体系,为平台建设奠定空间信息基础与数据支持;
统一服务平台:
系统业务处理的逻辑平台,它通过对数据核心层的调用访问业务数据,实现不同的功能模块,满足不同的业务需求;所有业务功能在此统一平台上得到良好的封装和定义,以Web、手机终端服务的形式,运作在平台上,为用户提供各类信息服务;
应用层:
对于应用层,提供多样化的界面逻辑,实现对业务逻辑的应用;主要提供房源管理子系统、合同管理子系统、主体管理子系统、资金管理子系统、联动管理子系统、企业培训子系统等。
3.4.架构设计
1.需要采用B/S多层体系结构:
系统需要采用B/S多层体系结构实现。
三层结构包括表示层、业务逻辑层、数据访问层;
2.需要采用面向服务的架构(SOA):
为了降低服务架构模块之间的耦合度,增强系统的可扩展性;需要采用面向服务的构架(SOA),各个功能模块分别提供不同的服务,通过服务总线集成为用户提供一体化的服务;
3.需要基于J2EE体系:
为了保证系统的兼容性,高可用性、高可靠性和可扩展性,系统必须沿用前期项目的技术路线,要选择支持强大的企业级计算的成熟的J2EE企业标准;
4.需要基于Web服务(WebService):
为了让地理上分布在不同区域的计算机和设备一起工作,以便为用户提供各种各样的服务。
用户可以控制要获取信息的内容、时间、方式,而不必像现在这样在无数个信息孤岛中浏览,去寻找自己所需要的信息,系统对外接口统一需要采用WebService服务的方式定义;
5.需要采取XML数据交换:
系统的外部接口需要采用XML数据交换格式,用XML作为数据定义和交换的中介。
3.5.数据库设计
3.5.1.历史数据库设计
历史数据库用来存储实时数据库的历史数据。
实时数据库中只有各种设备的当前值(状态),而以前的实时数据要存储在历史数据库中,以备日后查询。
为了可以精确获取每个数据采集仪的任何时候状态,历史数据库中要保存所有节点的全部采样数据。
历史数据库系统采用大型商用关系型数据库。
历史数据库系统是整个应用程序的数据层。
它为各种客户提供所需要的历史数据。
历史数据库系统采用双机备用方式。
历史数据服务库系统的功能包括:
采样历史数据的存储;计算各种分析所需的统计数据;记录变位、SOE等随机性数据;记录用户对应用程序的操作的日信息;存储用户权限等安全信息;提供Web发布所需的各种历史数据。
历史数据库系统的数据源由实时数据库系统提供,在实时数据库系统中,已经对数据质量、数据一致性、完整性作了处理,因此由实时数据库系统提供给历史数据库系统的数据均为有效数据。
实时数据库系统负责定时的将有效数据送给历史数据库系统的代理程序,随机数据在产生的时候送给代理程序,代理程序负责将数据写入历史库中。
同时代理程序负责定时对采样数据进行统计、计算并将结果存入数据库中。
历史数据系统示意图
3.5.2.历史数据
由实时数据库提供的采样数据存储在历史数据库中。
这些数据按类别、时间存储在数据库不同的历史表中。
I数据表命名规则
历史数据表名称按照一定的命名规则:
类型名称+时间。
如:
2001年7月10日的模拟量采样数据表应命名为SmpAna20010710,这张表将存储这一天的所有的模拟量采样数据。
以上设计主要基于对采样数据的查询方式,主要是要某一个量在某一段具体时间内的数据。
数据不存放在一个数据表中,可以大减少检索的次数。
当检索一个数据的时候,是先从系统数据表中检索出这张表的位置,然后定位这张表,再检索需要的数据。
而不必从一个大表中反复的检索、查找和定位。
这种检索方式也近似于字典查找的算法理论。
对于计算、统计数据也采用近似的处理方式。
II数据表索引(Index)
数据库的索引是一个B型树的数据结构。
当写入一记录时,数据库会对记录产生一个索引值,并在系统索引表(Sysindexes)中产生一条索引记录。
在检索一条记录时,从树的根节点到树叶的搜索方式进行,从而对有索引的记录加快检索速度。
但同时也降低了写入的速度。
对于采样数据,主要是记录值,因此可以考虑用没索引的表来表示。
III数据压缩存储
采样数据可能是一些不断重复的量。
重复记录会加大存储的空间和记录的行数。
因此可考虑数据变化时才存储,记录一个状态(值),并记录这个状态(值)重复的次数。
也就是:
数值—变化的压缩方式。
具体设计如下例:
如有一个模拟量,前一次的值如果和本次的值相同,则在记录中的次数计数器加1,否则添加一条记录。
3.5.3.统计数据
历史数据的存储方式同样是将数据按类分散在不同的表中,表要具有统一的命名规则。
数据统计是将各种采样数据计算生成所需要的一些统计数据。
数据统计与采样数据记录是同步进行的。
也就是说,当从实时数据库中取得采样数据并写入到采样记录表中的时候,就会触发一系列的统计和计算工作。
有一系列的中间结果产生出来,当在时间上满足要求的时候,就会将这个中间结果记录到相应的统计数据表中。
统计计算工作用ORACLE的触发器(Trigger)来完成,当采样数据更新时,会触发一系列的事件产生,事件驱动一系列的处理程序来处理是否写入数据库,更新统计数据的中间结果等。
这项工作在ORACLE后台为处理,使用大量的存储过程来加以实现。
3.5.4.临时表
临时表具有与普通表完全一样的属性,所不同的是它存储在Tempdb中而不放在当前数据库中,当用户连接并创建使用时它存在,当用户断开后临时表也会自动删除。
全局性临时表(以##开头作为标识):
会各所有连接到数据库的用户开放,每一个用户均可以访问,只有当所有的用户都断开后,全局性临时表才会自动删除。
临时表的设计主要是为了考虑提高对报表、查询速度的要求。
通过组态的报表或定制的某个查询,是对固定的一些参数进行数据检索,这些量使用的频率最高。
考虑减少在无关的数据堆中检索的次数,因此想把这些用户最关心的数据量的记录放在一个专门的地方。
由于数据源的记录本来已在数据库中存在,而同样的数据在数据库中不应该重复,所以考虑将这样的数据放在临时表中,且为全局性临时表,为所有的数据连接用户开放。
临时表中的记录是最近一个时间段的数据和最近使用过的数据。
处理临时表中记录的算法应是先进先出的原则和最久不使用原则。
新数据将最老的数据并且最久没有使用过的数据覆盖。
临时表中的数据始终保持最新和最新使用过的数据。
这些数据也是用户使用频率最高的数据,这样可以提高报表、查询的检索数据速度。
3.5.5.数据冗余处理
数据冗余采用磁盘阵列的方式来实现。
数据冗余示意图
3.5.6.数据库安全
数据库安全性问题一直是系统安全的关键。
数据库安全性问题应包括两个部分:
(1)数据库数据的安全
它应能确保当数据库系统DownTime时,当数据库数据存储媒体被破坏时以及当数据库用户误操作时,数据库数据信息不至于丢失。
数据安全的解决,主要有系统双机热备份、数据库的备份和恢复等办法,本系统的数据安全,纳入信息中心的系统安全体系,共享一些硬件设施,实现数据的备份等。
(2)用户角色的管理:
这是保护数据库系统安全的重要手段之一。
它通过建立不同的用户组和用户口令验证,可以有效地防止非法的Oracle用户进入数据库系统,造成不必要的麻烦和损坏;另外在Oracle数据库中,可以通过授权来对Oracle用户的操作进行限制,即允许一些用户可以对Oracle服务器进行访问,也就是说对整个数据库具有读写的权利,而大多数用户只能在同组内进行读写或对整个数据库只具有读的权利。
在此,特别强调对SYS和SYSTEM两个特殊账户的保密管理。
为了保护Oracle服务器的安全,应保证$ORACLE_HOME/bin目录下的所有内容的所有权为Oracle用户所有。
为了加强数据库在网络中的安全性,对于远程用户,应使用加密方式通过密码来访问数据库,加强网络上的DBA权限控制,如拒绝远程的DBA访问等。
3.5.7.数据库管理设计方案
本系统的数据库属于生产数据库,应当将其运行在归档模式下。
各种数据库备份和恢复方案各有优劣,为了保证数据绝对安全,本系统数据库备份和恢复将同时采用多种方案,以应对数据库不同的故障情况:
3.5.7.1.逻辑备份
用exp命令将数据导出为dmp文件,当数据库服务器崩溃时,用imp命令将数据重新导入,实现数据的恢复。
写一个批处理文件(bat)脚本,调用exp命令,利用windows提供的“计划任务”功能,达到定时自动导出的目的,考虑到系统性能,应将自动导出的操作时间设在系统应用的非高峰期,如中午12:
30分,晚上0:
00。
导入工作需
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 政务 服务 预约 叫号 评价 系统 建设 方案