发布时间：2022-05-04 09:09:12
序言：写作是分享个人见解和探索未知领域的桥梁，我们为您精选了8篇的电子政务系统论文样本，期待这些样本能够为您提供丰富的参考和启发，请尽情阅读。
关键词：电子政务；体系结构
0引言
电子政务e-Governmentaffair是政府在其管理和服务职能中运用现代信息和通信技术，实现政府组织结构和工程流程的重组优化，超越时间、空间、和部门分割的制约，全方位地向社会提供优质、规范、透明的服务，使政府管理手段的变革。这里，介绍一下这个信息系统体系的结构，并提出自己的一点看法，旨在抛砖引玉，与各位导师、同学、同仁商榷。
1该市电子政务信息系统的技术介绍
导师与本小组接手的该市电子政务公共信息平台的建设规划，这个电子政务系统通过采用当前的先进技术，将软硬件集成起来，以克服体系结构不同及软件自身不成熟造成的影响。具体技术路线是：采用J2EE技术，保障系统的可伸缩性、可扩展性和开放性；系统采用框架体系设计，数据库采用高可用容技术，应用中间件采用cluster（集群）技术，保证平台从信息存储到信息都具有较高的稳定性、开放性和高集成性；系统采用B/S+C/S结构，底层为数据层，存取关系型数据、文档型数据和其他业务系统数据，中间层基于应用服务器，各种业务组件注册在应用服务器上进行管理，采用XML进行数据的组织，通过JSP构造好用户访问界面并把各种业务逻辑连接起来，通过WEB服务层响应客户端的请求，客户端采用浏览器方式进行访问。该电子政务系统的主要建设过程和结构如下：
2该市电子政务信息系统的功能结构介绍
该市国产化电子政务平台正常运转一年多，平台上已经实现了市政府门户网站及90多个部门的分网站的、“诚信企业”企业信用数据交换系统、公务员的电子邮件系统、远程办公信息交换系统、办公信息资源管理系统、网上市民对话服务系统、网上电子表单下载系统等多项应用。
2.1政府门户网站。政府门户网站是该市国产化电子政务平台上第一项应用，网站分简体中文、繁体中文、英文、日文、韩文五种语言版本，设有烟台概况、政务、经济、投资、生活、科教、择业、旅游、参政、在线服务、县市区、数字地图、政府信箱等13个主栏目；今日新闻、政务动态、诚信动态、市民手册、政府文件、政务公开、电子商务等18个板块栏目和市民、企业、农民、投资者、旅游者、学生、公务员、弱势群体等8个定制频道。总信息量达两百多万条，日访问量超过两万多人次。
2.2该市政府部门网站。该市电子政务平台上运行着90多个政府部门和单位的网站。政府门户网站与各部门网站之间统一通过平台进行连接、与管理。各部门的对外的数据、信息由平台统一管理，形成较完整的政务公共信息资源数据库。这种数据的高度集中存放，为信息资源的深度开发和综合利用打下了良好的基础。
2.3“诚信企业”企业信用数据交换系统。该市电子政务平台上运行的“诚信烟台”企业信用数据交换系统，实现了与工商局、人民银行、国税局、地税局、质监局、海关、法院、公安局、环保局、劳动保障局、建设局、信息产业局等部门和单位的实时数据交换，初步形成全市统一的企业信用信息数据库。
2.4远程办公信息交换系统。该市电子政务平台上运行的远程办公信息交换系统，解决了分布办公的部门之间、部门内部的文件及资料传递问题，实现了办公信息交换无纸化。远程办公信息交换系统具有用户管理、发文管理、收文管理、系统设置、文件库管理、在线帮助等功能。
2.5办公信息资源管理系统。该市电子政务平台上运行的办公信息资源管理系统是针对各类管理部门的具体业务需求而开发的，集文件管理、信息管理、业务管理、协同管理、知识管理等办公功能于一体，是具备与业务系统、门户网站接口的新型管理信息系统。该系统是实现办公信息资源的整合、提高办公效率和领导决策支持的有效工具。
2.6公务员电子信箱服务。该市电子政务平台采用国产的红旗WebMail分级多域的邮件系统，为70多个部门和单位的3000多用户提供电子邮件服务，日完成数万封邮件的收发和传递。
2.7网上市民对话服务系统。该市电子政务平台上运行的网上市民对话服务系统是政府部门与市民沟通、交流的平台。
2.8网上电子表单下载系统。该市电子政务平台上运行的网上电子表单下载系统，提供了30多个部门的280多项行政审批事项的表单下载服务，50多个部门的580多项办事指南，实现了网上纳税和部分业务网上申报等功能。
3该市电子政务信息系统的层次结构
考虑到政府门户建设的现在和发展需求，系统应用平台具备跨平台、支持多种数据库环境的能力，采用构件化设计方式，易于扩展和维护。
从逻辑体系架构来看，如上图，办公信息系统分为多个层次：
3.1用户层：与系统连接的外部实体。用户通过浏览器访问管理信息系统。具有交互功能，进行填写信息、提交请求的操作，请求结果返回在客户端显示。
3.2权限控制层：按照用户管理和权限控制列表，审核用户的合法性和访问权限，保证系统和信息安全。用户个性化界面控制。
3.3表示层：对最终用户提供友好的界面，更好地为系统用户提供优质服务。
3.4信息接入层：这层中的Web服务器用于对外提供基本的静态信息传递服务，向后台应用服务器提供客户请求信息并接收返回的信息。
3.5应用层：完成业务的逻辑控制和流程处理，进行初步的应用安全控制和权限检查，记录原始的交易日志，进行交易的存储转发等。
3.6数据访问层：采用统一的方法访问后台数据。这层中的数据库系统用于结构化信息的存储和处理，是系统的数据核心。邮件服务器用于提供系统的邮件支持。
3.7系统层：提供应用系统的运行环境平台和对硬件系统的管理操作。
3.8硬件层：提供整个系统的硬件平台，确保系统正常运行。
4总结
该市电子政务公共信息平台按照“以实际应用为主导，以资源整合为主线，优先使用国产产品，全面引入市场机制”的建设思路，注重实效，力求实现政府部门通过一个统一的平台，及时各类政策法规和政务信息，提高政府公共服务水平和社会管理能力。
参考文献：
经过SARS等一系列公共卫生突发事件后，应急信息系统的建设受到了空前的重视。我国各级政府、各部门都把应急信息系统或应急指挥中心的建设提上了议事日程。例如，北京市公共卫生信息应用系统的建设，就是在以往的经验教训基础上，把应对公共卫生突发事件作为一个主要建设目标；卫生部应急指挥中心向社会公开招标，征集建设方案，等等。在政府推动下，应急信息系统建设已经进入一个高峰期。
应急信息系统的建设受到全社会范围的重视，这是一件好事。但同时也带来了问题：系统建设的目标到底是什么？多个相关项目如何统筹？怎样处理应急信息系统建设与业务处理系统的关系？应急信息系统的功能边界应该如何划分？等等。对这些问题如果没有一个正确的思路，应急信息系统建设的大规模投入就难以收到应有的社会效益，甚至象以前办公自动化和门户网站一样，变为一场“运动”。
本文试图对应急信息系统给出一个目标，描述“理想”情况下的系统模型和需求；在此基础上给出对整个应急信息系统规划的看法。
二、应急信息系统的目标和功能需求分析
应急信息系统的目标，就是配合危机管理的全过程，应用信息技术，实现大面积的、跨专业和部门的信息资源、处理资源和通讯资源的实时调度，使应急指挥过程更加科学化和可视化。
这里用到了一个超越“应急”的概念——危机管理，我们把支持危机管理作为应急信息系统的目标。这是因为，要最大限度减少各种突发或紧急事件带来的损失，不仅仅要求我们在事件发生后做出迅速、准确的应对和处理，还要求我们在事件前期进行预警和辨识、在后期进行常态恢复。“危机管理”的三阶段理论更能指导我们运用信息技术对突发或紧急事件全面、全程的支持。
显然，这一目标，不是一个单纯的信息系统可以达到的。它要依赖基础性的网络和多个专业化的应用系统，要依赖多种技术的支持。但是，越是复杂，我们就越应该分析清楚，那些是核心、哪些是基础、哪些是锦上添花；哪些应该先建，哪些可以后建。否则眉毛胡子一把抓，不利于复杂系统的建设和统一的规划。
我们用如下的三层逻辑模型表示应急信息系统及其支持系统的关系。
……
应急信息系统
信息处
理系统
通讯调
度系统
信息
采集
信息
调度
资源
调度
信息
表现
基本网络和通讯系统
辅助
决策
应用支持层
集成应用层
基础设施层
GIS
应急信息系统的三层逻辑模型
各层的关系如下：最高层即是应急信息系统的核心功能，它是一种集成式应用；专业化的信息处理系统和各种相对成熟的技术系统（如GIS和Call Center系统）是构建应急信息系统的支撑性应用，我们称之为应用支撑层；而基本网络和通信系统是以上所有应用的基础。相邻层次之间有着双向的信息供求关系。
我们从对信息的处理角度来分解应急信息系统的功能目标。
任何类型和目的的应急指挥系统，都具有以下功能特性：
1、信息汇聚：从应急事件现场或监测网络采集到的各种信息，将被传输到信息汇聚点（应急指挥中心）。这些信息可能是直接事件现场的视音频信息，也可能是来自传感设备、监控设备的信息或信号，还可能是来自相关的专业化信息处理系统的数字化信息。
2、信息表现：应急信息系统应该有直观而准确的信息表现形式，为指挥员进行指挥调度和辅助决策提供最大的帮助。GIS是一项广泛使用的技术，可以将危机管理所涉及的信息（如危机态势、应急指挥相关资源分布、应急方案等）在基础的空间地理图形上形象地表现出来，便于指挥和决策人员直观地进行形式判断、形成决策或进行资源调度；各种信息还可能要借助一定的显示设备和显示控制系统表现出来。
3、信息调度：所有信息在汇聚点被组合和集中呈现，供指挥中心的指挥决策人员作为决策和调度依据；有时还要将信息分发下级指挥中心（或分中心）的不同的专业化处理系统进行处理，或从这些系统收集处理结果。
4、通讯和物资资源调度：应急指挥最终都表现为通过一定的通讯手段，完成一定的人力、物力资源调度。例如警力的调度、救灾物资和设施调度、对事件现场的疏导和部署，等等。
5、辅助分析决策：在应急指挥过程中，提供一些逻辑分析模型、统计模型或预案，以及案例库中的参考案例，帮助指挥员进行理性决策；同时，应急信息系统还应记录下整个指挥调度的过程，形成完整案例，丰富案例库，为实现知识化、智能化的危机管理作积累。
以上是一个较为抽象的逻辑功能模型，它有助于我们把握应急信息系统的核心建设目标，合理运用各种技术和各种“物理的”系统。
三、应急信息系统与其它信息系统的周边关系
1、技术型应用系统与应急信息系统的关系
在应急信息系统建设领域的最大误区，在于信息系统功能需求分析的缺失——从需求的陈述（实质上是一种需求定义）直接跳到技术方案，甚至成为技术方案或产品的简单堆砌。以技术方案代替功能需求，这似乎已经成为了一种应急信息系统建设中的普遍现象。
例如，我们经常能在招标书或所谓规划中看到这样的做法：即直接把“数字录音系统”、“大屏幕显示系统”、“地理信息系统”等作为“需求”本身的内容，对具体的技术实施方案和产品型号进行招标，甚至还有的招标书把“数据库系统”也作为应急信息系统需求的一部份提出来。这里面缺少了对应急信息系统的实质内容和目标的把握，缺少了一个理性的论证和分析过程。这样的“需求”拿出来招标，多半会造成建设的混乱和失控。
并不是说以上的技术系统不能作为应急信息系统的一部分，相反，逻辑的功能最终都会落实为一系列“物理”的技术子系统。但是我们在进行技术子系统的划分和分包之前，有必要对有机信息系统的“原始”功能需求作一定义和陈述，为技术方案的展开提供理性的约束，而不会被技术牵着鼻子走。
例如，GIS是一种广泛使用的、成熟的技术，也已经形成相对独立运行的系统。独立运行的GIS甚至可能成为整个应急信息系统中最主要的操作平台。这也是一些项目直接把GIS作为一种“默认”的“需求”的原因。但是，应急信息系统是否要采纳GIS，还要看具体的应用领域是否具备了应用GIS的数据条件和环境。而且，即使有必要和有条件使用GIS，也要从整个应急信息系统的总体目标出发进行分析，提出技术应用需求：
第一， 要实现应急信息系统与GIS的双向联动。GIS虽然可以独立运行，但在应急信息系统环境下，应该可以实现应急信息系统与GIS的多种联动方式——包括双向的相互驱动和基于数据共享的独立操作，等等；
第二， 要实现应急信息系统与GIS的底层整合。GIS系统与应急信息系统应共同遵循一定的数据标准，产生和传递一致的数据；底层应实现数据库共享或公用。
第三， GIS与其他系统的数据整合。GIS的基础数据来自测绘部门，而应急指挥所需的“活”的应用数据往往来自其他业务部门，如建设、交通、气象、卫生，等等。为让信息系统能够运行起来而“一劳永逸”地导入数据的做法是不可取的。应该充分利用这些“活”的地理数据，建立与数据源进行同步更新的完整机制，贯彻专用属性数据“谁使用、谁负责”和合理共享的原则，避免产生新的信息孤岛。
以上是应急信息系统中对GIS的需求分析应该考虑的内容。只有对这些问题都分析清楚了，才可能对应急信息系统中GIS的必要性、可行性和技术方案和造价作一正确判断。而这种全局的、客观的、中立的分析，恐怕要在请GIS厂商提供技术方案之前完成。
在应急信息系统领域，类似的成熟技术系统还有Call Center、知识管理系统、视频会议和视频监控系统等。对这些相对成熟、“自成一体”的技术应用系统，都要作类似的分析，才能保证最后的应急信息系统是一个有机的、完整的、体现建设初衷的系统，而不是一组不分主次、繁复、独立的技术系统。
忽视需求分析或缺乏正确的需求分析方法，是存在于信息化建设的通病。对于应急信息系统建设而言，这种只有方案，没有需求分析的现象尤其有害。因为应急信息系统的建设几乎成了一种潮流，而且它同时承载着政府危机管理和电子政务信息资源整合的双重重任。缺乏对需求的分析和规划，会使应急信息系统建设失去理性，导致盲目建设和重复建设，与信息资源整合的精神背道而驰。
2、专业化信息处理系统与应急信息系统的关系
我们对应急信息系统的需求认识往往是始于“混沌”的。尤其是当因为信息系统缺位造成重大损失的时候，更是希望通过一个项目、甚至一个系统的建设毕其功于一役。但是，应急信息系统的主要目标是实现危机管理中的决策支持，离开了专业领域的知识和专业化的信息处理系统的支持，应急信息系统对科学决策的支持就会落空。另一方面，应急信息系统往往是跨管理部门、跨专业领域的系统，涉及多个专业系统。处理这种兼具“宽度”和“深度”的复杂需求的合理做法，是把项目进行分解，把应急信息系统建设与专业化信息处理系统进行合理划分。
一般来说，专业化信息系统负责专业化的信息监测和预警、信息处理；应急信息系统则负责信息的汇聚、分析，以及对会商、决策和资源调度的支持；二种系统之间通过共同认可的标准来实现信息传递和工作协同。应急信息系统从专业化信息处理系统中收集预警监测的结果；应急信息系统则向专业化信息处理系统提交信息加工请求并收集信息处理结果。
检验是否较好划分了专业化信息处理系统和应急信息系统界限的直接办法，是看二者之间是否有足够的独立性。一个好的规划和设计应该是这样的情形：应急信息系统本身不一定很“专业”，但它能与很专业化的信息处理系统高效地协同工作。应急信息系统的核心价值，在于它对跨专业的、公用资源的调度能力；专业的判断和业务流程应该留给专业化的信息处理系统。从这点上来说，应急信息系统其实需要有一定的“通用性”。通用性越好，它动态“接入”不同专业信息系统的能力就越强，整个大系统的“应急”能力也就越好。
举个例子，假设我们针对SARS的预防和控制建设了一个公共卫生应急信息系统，如果它不能百分之八十、九十，甚至更高比例地应用到其它公共卫生突发事件的处理上，那么它的规划和需求定义就是失败的。相反，如果我们在进行需求分析的时候，能把专业化事件处理的差异性需求尽可能地体现在“应用支持层”的专业化信息处理系统中，那么无论是作为通用应急指挥平台的公共卫生应急信息系统，还是专业化的传染病管理信息系统、医院管理信息系统、以及各种科研信息系统，等等，都能沿着相对稳固的需求轨迹发展。
四、应急信息系统的规划与标准化
现在我们跳出单个应急信息系统的需求分析，来看看多个系统——或者说整个城市级别的应急信息系统——的需求，或者说一种规划。
根据上面的分析可知，我们如果采用一个相对通用的“应急信息系统”和一系列专业化信息处理系统，可以构成一个完整的、面向各种突发事件的应急信息系统“两层”构架。也即从理论上说，可以构建城市级别的唯一的、集中的、公用的应急信息系统平台。但在实际操作中，有两个因素制约这种“两层架构”模式。一是系统的规模和负载问题；二是现有的行政管理体制的制约。
根据系统论的原理和系统工程实践经验，每个系统下辖的子系统个数是有限的，超出这一限度，不仅系统的业务负载和复杂度会难以承受，为保障系统运行可靠性所付出的代价也会十分巨大。我们通常采用系统分级的办法来解决这一问题。在应急信息系统建设中，就是通过建立一些区域的或“领域”分中心来分担“总中心”的负载和复杂性。
但是，采用分中心的“三层”构架，应该满足两个先决条件。否则，就有可能使整个城市的应急信息系统更加混乱和难于管理，操作起来无所适从，甚至变成一盘散沙，为信息资源综合增加新的负担。
第一个条件，还是比较、分析和论证。在具体的城市危机管理环境中采用三层构架，一定要有与两层构架的对比分析。三层系统的优势在于其上的业务操作流程通常可以更好吻合现有管理体制；劣势是分级处理带来了额外的信息分配和汇总的效率开销，甚至为一些导致低效的“门槛”创造了条件。我们对架构进行分析的结果，应该不仅仅是一个构架的模式，而且有具体的构架实施方案，包括对弱点的分析，以及弥补的方法，作为系统后续建设的前提条件。这是应该在决定建分中心之前完成的。
在实际建设过程中，对于城市应急信息系统的构架模式选择，盲目模仿或是“拍脑袋”的情况还是很多的。构架的选择往往不是对流程科学性、系统运行效率、系统建设周期和投入、系统的可操作性等因素进行分析比较的结果，而是避开业务整合的深层困难、对现有管理体制过分迁就和妥协的结果。这对于整个城市的危机管理和信息化建设都是非常不利的。
第二个条件，无论是二层还是三层构架，都离不开标准化基础。统一的数据标准制定应该在应急信息系统的总体规划层面，而不是某个具体的应急信息系统建设的层面来进行。在某个具体应用系统中谈统一标准的意义是十分有限的。即使每个系统都实现了“内部”的统一标准，也可能导致多个系统之间无法沟通。
对于标准化的认识，也是信息化建设中误区多多的一个领域。如把统一数据规划甚至统一数据库设计等同为数据标准化，把标准化局限于管理标准化而无视应用标准化，把应急信息系统的标准化局限于应急事件的分级，等等。应用标准化是我国信息化建设的一个弱点和紧迫点，也是应急信息系统建设的一项基础性工作。如果能在国家层面整合专业化研究资源，组织面向应急指挥和危机管理的统一的标准化研究，则能有效促进整个国家的应急信息系统的建设；反之，如果我们不抓住应急信息系统这一建设背景，则不仅应急信息系统的建设不能进入有序状态，标准化建设本身也将摆脱不了滞后于信息系统建设的状况。（参考《把标准做“实”》）。
参考文献：
1.
《把标准做“实”》 黄以宽，《信息化建设》2005-1，2
2.
《浅论应急指挥系统的基础性研究》，黄以宽，第一届中国政府电子政务论坛交流论文，2004-10
