全科网格系统建设方案

《全科网格系统建设方案》由会员分享，可在线阅读，更多相关《全科网格系统建设方案（19页珍藏版）》请在装配图网上搜索。

1、全科网格系统建设方案19目录第一章项目概述31.1 项目名称31.2 建设单位31.3 建设依据3第二章技术方案32.1 技术路线设计52.1.1 概述52.1.2技术路线选择52.1.3技术开发方案72.1.4关键技术说明72.1.4.1 J2EE 基础技术架构 72.1.4.2 SOA 面向服务架构92.1.4.3 XML 可扩展置标语言112.1.4.4 Web Service 技术112.1.5技术路线优势122.1.6系统总体架构图132.2建设目标152.3 应用系统设计152.3.1综治网格管理152.3.1.1 网格划分152.3.1.2 网格调整152.3.1.3 网格查询1

2、62.3.1.4网格初始化162.3.1.5 网格审核162.3.2网格应用共享服务162.3.3网格三实一标数据共享服务162.3.4全科网格责任平台162.3.5 网格信息汇聚平台172.3.6 网格服务请求平台172.3.7 网格员薪资报酬平台172.3.8网格员职能模型172.3.9统一业务支撑平台172.3.9.1统一身份认证182.3.9.2工作流子系统182.3.9.3表单管理子系统18第三章组织保障18第四章实施进度计划19第五章项目预算195.1总投资预算19第一章 项目概述1.1 项目名称项目名称：全科网格系统建设项目1.2 建设单位牵头单位：配合单位：政府办、宣传部、发改

3、委、工信局、公安局、财政局、住建局等.1.3 建设依据全球化、市场化、信息化背景下，如何让基层社会实现良性治理，是世界各 国面临的共同课题，对经济社会处于快速转型期的中国，显得尤为紧迫。党的十 八大以来，以习近平同志为核心的党中央，从党和国家发展全局的高度，围绕加 强和创新基层治理提出了一系列新观点、新论断、新要求。加强和创新基层治理， 是一项复杂的系统工程，需要各地立足实际，把握新形势，拓展新思路，探索新 机制。近年来，针对基层治理的现实困难与问题，紧紧围绕平台、人员、网格和 机制等四大要素，健全组织体系、队伍体系、责任体系和支撑体系这四大体系， 深入推进“全科网格”建设工作，并融入经济社会

4、发展各方面和全过程，带动市 场提升发展、产业转型发展、城乡统筹发展、生态文明发展、社会和谐发展，初 步探索出一条符合本地实际的基层治理新路。第二章 技术方案本项目设计符合相应的国际、国家标准和规范。在项目设计中，应重点考虑具备先进性、可靠性、实用性和经济性，使系统具有扩展性的升级能力、安全性 和保密性、标准化和开放性、灵活性和兼容性。(1) 标准化原则。本项目中所有应用系统的接口、网络数据格式等将严格 遵循标准化，对于部分非标准的业务应用内容，也将根据采购人与技术支持单位 业务的实际情况，为工作人员设计弹性化的系统应用，以确保与其他标准化应用 的充分兼容。(2) 访问速度优先原则。本项目采用微

5、软DIA结构、互联网技术、多媒体 技术等技术进行开发，在保证质量的基础上尽可能减少文件大小，以满足网络传 输的需求；互动过程的网络带宽要求应适合一般带宽接入环境的网络用户访问。(3) “KISS原则”(Keep It Simple and Stupid)。良好的用户体验包括体 验过程的可用性和易用性；在体验和互动过程中应实现自然的过渡和前后联系； 同时隐含了表现形式的美观，不可一味追求强大的系统功能而忽视了所要传达的 操作简洁化内涵。(4) 扩展性原则。扩展性原则包含2个方面的含义，一是系统功能的扩展， 随着信息化建设的不断深入，系统的功能可能将进一步扩大，因此软件系统的建 设应具备很强的扩展

6、能力，方便以后更多功能模块的逐步应用；二是用户数量的 扩展，由于采购人与技术支持单位工作的不断开展和中心业务的不断增加，势必 将带来管理用户的增加，使软件用户数量增多，本系统建设应具备随时扩充用户 的能力。系统采用“活页夹”式结构设计，可自由组合功能模块，以搭建不同应 用，有效地保证在各个应用层面的可伸缩性。(5) 大集中原则。方案设计需要以集中和分布相结合为原则。本项目的设 计采用数据集中、业务和服务分布的原则，使数据的处理最终在统一资源中心进 行数据的汇总和分析。通过对整个体系框架实行分层、逐级设置权限操作，为内、 外部提供有效、充分的操作手段。(6) 安全性和稳定性原则。本系统的设计和建

7、设充分考虑到网络的安全性 和稳定性，能保证各种在网数据安全、完整，保证各类网络应用的畅通和稳定。 系统本身的容错能力、纠错能力及输入数据的自动检验是系统安全稳定的重要部 分。在各系统设计中，全面考虑系统安全性。采用集中化的用户管理，实现基于 角色的安全策略和统一的认证及授权。重要资料的通讯进行传输加密。2.1 技术路线设计我们将选择科学、先进、成熟、合理的技术路线和开发方案，保证项目应用 系统的全面实用化以及系统的安全性、先进性、开放性、扩展性等特性，而且， 确保符合技术发展趋势。2.1.1 概述技术路线的选择取决于有关规范标准、应用系统的需求和软件开发技术架 构的发展情况。构建本项目的技术路

8、线需要具备以下特征：符合国家、行业相关规划及规范要求；保证实用化应用的实现，具有先进性、成熟性、安全性、先进性、开放性、易扩展性、易维护性； 支持 B/S 多层体系构架； 具有跨平台特性，独立于硬件平台和操作系统，能够支持 Windows、UNIX 以及 Linux 等主流操作系统，支持各种主流的硬件平台； 支持文档型数据库和主流的关系数据库系统； 采用 SOA 架构，支持组件技术，便于快速开发和热部署； 应以开放的标准为基础，采用国际上成熟的、先进的、具有多厂商广泛支持的软硬件技术来实现，保证系统整体架构在未来几年内不落后； 整个系统架构必须具有良好的可实施性与可管理性，同时还要具有较好的易

9、维护性； 系统应具有良好的可伸缩性，系统架构应留有接口，包括与其它相关业务信息系统、办公自动化系统等的数据接口。2.1.2 技术路线选择基于以上考虑，本项目建设应统一采用如下关键技术：根据应用系统的业务类型我们建议采用J2EE的技术路线，采用SOA架构 建设业务应用系统，可跨平台并支持文档型数据库与关系型数据库。 采用先进的数据整合技术。数据采用可扩展的 XML 格式存储，可以实时抽取相关异构数据库数据并整合；数据提供统一、安全的管理，数 据查询支持 XQuery (XQueryl.O)查询和 SQL (SQL92、SQL99)查询； 支持W3C XML的相关标准，同时支持基于XML的电子公文

10、格式规范 (GB/T 19667.1-2005)国家标准。 基于组件模式的系统架构，各个功能组件都能够分开部署，并使用成熟产品整合。 系统在设计、实现过程中将提供标准和开放的平台接口，要求有良好的可扩展性，可以方便地集成新的数据信息和支持新的应用系统。 XML用于业务数据交换的封装和标准。 LDAP协议的目录服务一一用于统一的用户管理和资源管理。提供基于目录服务(LDAP)技术的组织机构、岗位分工、职权匹配、用户权限等 管理。支持用户“单点登录/一次退出”。 采用全方位的安全机制。包括严格合理的权限设置，能自动记录任务执行过程和监控信息的系统日志，能多层次保留文档修改痕迹和审批人 的电子签名。

11、 在业务流程中，提供 Web 图形化工作流程定制功能，保证系统能随时适应公务活动程序的变换及新应用的扩展，过程中支持Word、WPS 等常规文字编辑工具，在各种审批活动中支持领导手写签名。 系统具有一定的知识库功能，提供数据挖掘支持，尽量减少用户数据输入量。基于WSDL、SOAP、UDDI技术的Web Services用于实现数据交换的 方法和通道。 层次化，组件化结构设计，使平台功能模块易于改动、维护和升级。在界面设计和实现方面，达到界面美观大方、人性化，操作简单、便 捷。2.1.3 技术开发方案根据上述技术路线选择方案及项目建设要求，我们为本项目建议的技术开发方案如下：序号项目可选方案1服

12、务端操作系统支 持 ： Susell SP2 ， RedHatEnterprise Linux6.2, Windows 2003/2008/2012 Server， IBM AIX7.1, 0racleSolaris11 及以上版本2客户端操作系统支持：WindowsXP、Windows Vista、Windows7；智能手 机-IPhoneiOS、Android 等3关系数据库管理系统Mysql 5.5、ORALCE 10G 以上4应用服务器中间件支持：IBM Websphere、Oracle Weblogic、BES AppServer 等。5客户端PC Web浏览器、智能手机安全客户端6

13、平台架构J2EE + SOA + B/S/D7开发技术Java、Web Service、JavaScript、SOAP、XML8开发管理工具Eclipse： Java应用程序开发DreameWeaver：设计页面版式、操作界面 Studio MX with Flash Professional：网页制作 Adobe Photoshop CS：图像处理MS Project：项目管理工具2.1.4 关键技术说明2.1.4.1 J2EE 基础技术架构J2EE 是一套全然不同于传统应用开发的技术架构，包含许多组件，主要可 以简化并规范应用系统的开发与部署，进而提高可移植性、安全与再用价值。 其核心是一

14、组技术规范与指南，其中所包含的各类组件、服务架构及技术层 次，均有共通的标准及规格，让各种依循 J2EE 架构的不同平台之间，存在良好 的兼容性，解决过去后端使用的信息产品彼此之间无法兼容，导致应用系统之间难以互通的窘境。J2EE技术架构体系由一整套服务(Services)、应用程序接口 (APIs)和协议 构成，它对开发基于Web的多层应用提供了全面支持。主要包括了 13种核心技 术：JDBC、 JNDI、 EJBs、 RMI、 JSP、 Java servlets、 XML、 JMS、 Java IDL、 JTS、 JTA、 JavaMail 和 JAF。J2EE 规范包含了如下表所示的多

15、种技术，这些技术形成一个有机的框架：项目描述EJB企业级Java组件，能够封装复杂的业务逻辑，并在整个系统范围内重用， 支持远程调用和集群RMI-IIOP远程方法调用协议，支持Java程序象调用本地对象一样调用远程对象，该 协议既支持Java本身的RMI调用，也支持CORBA的IIOP协议，因而能 够与CORBA服务进行互访问JDBC提供Java程序访问数据库的标准接口Servlet支持动态地生成Html页面，用于基于浏览器的应用开发JSP能够通过混合编写java和html脚本，动态地生成html页面，比编写Servlet 的开发效率更咼JTAJava事务接口，提供对事务的支持，包括分布式事务

16、Java IDL允许Java对象访问外部CORBA对象JMSJava消息服务，支持可靠的点对点、发布/订阅方式的消息传输JNDIJava命名和目录服务，支持按照名称来查找资源Java Mail提供在Java中发送和接收电子邮件的支持JAF被JavaMail用来处理MIME数据JAXPJava处理XML文件的标准接口，支持SAX和DOM APIJCA允许遗留的信息系统提供出适配器接口，与J2EE应用程序进行整合JAAS支持基于用户的认证和授权模型下图描述了 J2EE 体系结构：Web BrowserApplication ClientContainerApplicationClient丿zxJa

17、vaEE Application ServerJava Virtual Machine2.1.4.2 SOA 面向服务架构面向服务的架构(SOA , Service Oriented Architecture)，是一种指导创建 和使用商业服务的各个方面的纲要，定义和提供了一种允许不同应用交换数据 和参与业务过程的IT基础架构。SOA符合本项目系统实际需求和系统建设的技 术方针，而且随着目前几种主要的关键工业技术的发展，特别是 Web 服务技术 的普遍采用，SOA已成为行业信息化建设技术架构选择的方向。SOA是一个组件模型，它将应用程序的不同功能(称为服务)划分为服务， 通过这些服务之间定义良好

18、的接口和契约联系起来。接口是采用中立的方式进 行定义的，独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在 各种这样的系统中的服务可以以一种统一和通用的方式进行交互。SOA 架构主要包括四大功能模块：开发服务、发布服务、查找服务、使用 服务。这 3 种 SOA 参与者：服务提供者、服务中介者以及服务请求者通过 3 个基本操作：发布、寻找、系结相互作用。服务提供者开发出各种各样的有用 的服务，经过测试后把服务发布到公共的服务注册表上，向服务中介者发布服 务。服务请求者通过服务中介者查找服务注册表寻找并获得所需的服务，然后 便可以使用所需服务。SOA 体系架构具有以下特性：序号特性描述1S

19、OA服务具有平台独立的自我描述XML文档。Web服务描述语言(WSDL, Web Service Description Language)是用于描述服务的标准语言。2SOA服务用消息进行通信，该消息通常使用XML Schema来定义(也叫做XSD， XML Schema Definition)o消费者和提供者或消费者和服务之间的通信多见于不知道 提供者的环境中。服务间的通讯也可以看作内部处理的关键商业文档。3在一个内部环境，SOA服务通过一个扮演目录列表(directory listing)角色的登记 处(Registry)来进彳丁维护。应用程序在登记处(Registry)寻找并调用某项服务

20、。 统一描述，定义和集成(UDDI, Universal Description, Definition, and Integration) 是服务登记的标准。4每项SOA服务都有一个与之相关的服务品质(QoS, quality of service)o QoS的一 些关键元素有安全需求(例如认证和授权)，可靠通信(可靠消息是指确保消息“仅 且仅仅”发送一次，从而过滤重复信息)，以及谁能调用服务的策略。SOA 模型如下图所示：对象说明服务提供者服务提供者(Service provider)是一个网络节点，为处理一系列特定任务的软 件资源提供服务接口。服务提供者节点能代表商业实体的服务，或者甚至

21、能 代表可重用子系统(实现服务规范的软件实体)的服务接口。服务请求者服务请求者(Service requester)是一个网络节点，发现并呼叫其他的软件服 务来提供商业解决方案。服务请求者节点常常代表执行远程过程调用分布式 对象或者服务提供者的商业应用程序组件。提供者节点可能就在本地的内部 网内，或者在远程的因特网上。从概念上来说，SOA本质上是将网络、传输 协议和安全细节留给特定的实现来处理。通常称为客户端，但是，Services请 求者也可以是终端用户应用程序或别的服务。服务注册表服务注册表是一类充当注册表的特定服务提供者，允许寻找服务提供者接口 和服务位置。服务中介者服务中介者(Serv

22、ice broker)是一个网络节点，作为储存库，产生由服务提供 者发布的软件接口。商业实体或者独立的营运商能代表服务中介者。2.1.4.3 XML 可扩展置标语言XML(eXtensible Markup Language )是一种具有数据描述功能、高度结构性 及可验证性的置标语言，XML1.0规范是由W3C组织于1998年2月发布的。XML 允许用户自行定义标记和属性，并可以依照所定义的标记与属性的语法来开发 应用程序。可以通过标记来描述数据，或配合属性来辅助描述数据，因此， XML 十分适合用于作为对象或标准的描述语言；并且由于可以借助验证规则来 规范一个XML文件的内容和结构，所以XM

23、L又很适合用于做G2G、G2B或G2C 的数据交换格式。XML 相关概念和核心技术很多，共分为为三大部分： XML 核心和基础标 准、 XML 相关标准和应用标准。简述如下：XML 核心和基础标准包括 XML Namespace 、 XML Base、 XML Information Set、 Canonical XML、 XML Inclusions 等；XML 相关标准包括 DTD、 XML Schema 、 XLink、 XPath 、 XPointer 、 DOM、 SAX、 XSLT、 XQuery、 CSS、 XSL、 Xforms、 RDF 等；XML 应用标准包括 XHTML、

24、VoiceXML、ebXML、RDF 和 Web Service 等。2.1.4.4 Web Service 技术Web Service技术是利用标准的Web协议和可编程访问的Web组件，目标是 提供跨平台的互操作性，让分布在地理上不同区域的计算机和设备协同工作。Web Service将应用功能封装成若干Web组件，并将其发布在网上，供需要获得 这些功能的应用系统访问，而且各种应用系统间都能够通过这种方式进行互联 互通。整个 Web Service 的实现过程采用的都是标准的协议和技术。因此，按照 Web Service 架构设计的系统将具有很好的跨平台性和兼容性。同时， Web Servic

25、e 技术是一种松散耦合型的计算技术，因此，在跨系统的资源整合和一站 式应用服务系统的构建方面具有独特的优势。尽管Web Service有很多优势，但是，安全问题一直是其健康发展的障碍。 例如，在使用Web Service的过程中，用户必须知道所发布的Web组件是否经过 严格的安全认证控制；而且，Web Service应该能够识别用户的身份、相关的安 全服务策略以及用户的接入设备等，这些问题都是可信Web Service技术需要解 决的。可信 Web Service 技术是在 Web Service 基础之上提出来的。可信 Web Service通过可信SOAP技术来保证消息的可靠性，即消息的机

26、密性、完整性和不 可抵赖性；通过可信的 WSDL（Web Service Description Language ， Web 服务描述 语言）来描述可信的服务组件；通过可信的 UDDI（Universal Description、 Discovery and In tegratio n,统一描述、发现和集成协议）来发布可信服务组件。2.1.5 技术路线优势我们建议本项目的技术方案：采用 J2EE + SOA + 关系数据库 + 文档数据库 相结合，该方案具有如下优势：应用部署模式方面 采用虚拟机、应用集群等部署技术，在安性、高负载、可移植性等 方面均有保障。 有利于与相关应用之间的互联互通、

27、资源共享。 有利于投资保护。 系统体系架构方面采用SOA架构，全面支持B/S、B/A/S模式，便于系统集成和扩展。 符合政务信息化总体技术架构要求。 开发平台方面 技术架构的选择最重要的是为了实现业务需求，采用广泛应用的成 熟技术，能降低系统建设的风险。 充分考虑技术发展的前瞻性，符合政务信息化技术发展趋势。 数据库方面 充分利用了关系数据库擅长结构化数据处理、文档数据库擅长非结构数据处理技术，提升了各类数据的存储、检索能力，有效满足了 协同办公应用大量非结构化数据的存储和利用及安全控制要求。操作系统方面 所选择应用平台，都可支持各种主流的服务器系统、操作系统，保 证系统具有良好的开放性和可移

28、植性。 非功能性需求满足度方面遵循J2EE标准，采用服务组件和JAVA技术实现应用集成、档案管理 系统、数据的统计汇总和分析以及Notes文档数据库中部分业务逻 辑的实现，保证了系统的灵活性、可用性、可集成性、可扩展性和 可伸缩性。采用SOA架构，采用服务总线平台，提供对Web Service的支持，优 化了系统总体架构，为系统集成和扩展提供了统一的总线接口。2.1.6 系统总体架构图通过分类梳理、逐级分流、按责转办，形成常态化社会事务处置机制， 整合建立全科网格制度，全面提升基层统筹协调能力和管理服务能力，强化 在基层治理中的作用，逐步整合部门信息系统，打造集中统一、信息共享、 功能完善的信

29、息平台，以信息化提升基层治理水平，建立全方位全流程的监 督考核机制，切实推进智慧治理。从自身的架构上来说，科学的软件分成体系结构应能保证应用系统具备 可伸缩性、可扩展性和可管理性，而且，必须与国际上先进的理念相吻合， 这也正是基层平台信息系统的技术要求。因此，本系统采用多层体系结构， 自下而上由设施层、数据层、支撑层、应用层组成，通过统一信息交换体系 进行信息管理、统一运维管理体系进行系统管理、统一安全体系进行安全权 限管理： 数据层：包括基础数据库和专题数据库。基础数据库包括人口、法人、 空间地理等公共基础数据库。专题数据库主要包括事件、短信等各类业 务数据。支撑层：包括统一认证、数据交换、

30、文件服务、内容组件、工作流引擎、 消息服务、搜索引擎等支撑服务功能。应用层：包括网格应用共享服务、网格三实一标数据共享服务、全科网 格责任平台、网格信息汇聚平台、网格服务请求平台、网格员薪资报酬 平台、网格员职能模型等。系统架构图设计如下：网格应用喀9玲 舗格荷息5L聚平蓄）（河雹春蟲警）侄网格銅平R（阿冏轴繇平台）核心业务层标准与规范体系（生命月1世理：）幽控告售）（葩官連）雷全审计）（fi-fiafcs）用户也a）C计書愷is訶署迁着j大数据中心层 (盟挫系靖诸宀 |安全与保障体系Ml事曲拇库人口进?&廉 两卿虫辦a库 芳的轴谢a康 数据层图表-大联动业务协同平台架构设计图2.2 建设目标

31、按照“全科网格”的总体部署和一网覆盖的工作要求，全面整合民情通、平 安通、河长通、城管通等基层网格，融合多元功能，实现一员多用，逐步构建起 一张适应基层治理的综合网，使网格成为街道由村（居、社区）向下延伸的基层 社会治理的单元、管理服务依托的平台、政策传播宣传的前沿、信息采集收纳的 触角、服务人民群众的窗口，从而更好地发挥网格作用，提升基层社会治理水平， 推进基层治理的现代化，确保社会和谐稳定。2.3 应用系统设计本项目的综合信息管理平台是一个智能化、组件化、个性化的新一代智能综 合性平台，专门针对社会治理的业务规范和需求，并将结合本项目的具体需求进 行定制，采用J2EE多层体系结构、可信We

32、b Service集成，基于关系数据库和 文档数据库，使用统一的Web浏览器界面，保证了系统的先进性、开放性、可扩 展性和可集成性。2.3.1 综治网格管理2.3.1.1 网格划分可在地图上用多边形的方式划分出区域后保存到数据库中。同时可录入相关 的一些网格信息，如网格名称，编码等。2.3.1.2 网格调整通过网格区域的拉伸或重新划分，实现网格大小的调整、合并等工作。同时 可对网格信息进行编辑和修改等。变更过的网格原信息需要进行历史痕迹记录， 以备后续查找相关数据。2.3.1.3网格查询可以通过条件查询在地图上对下辖区域进行定查询位，查询结果显示出基本 信息。点击后可以编辑辖区的基本信息（接口

33、）。2.3.1.4网格初始化根据网格编制要求，实现全县网格定制化绘制，并且打印成册。2.3.1.5网格审核按照网格审批流程实现审核，支持多级审核和退办。2.3.2 网格应用共享服务基于GIS空间地理的网格共享服务平台，实现与智慧城市各部门业务系统集 成共享网格应用，配合基层全科网格打造。2.3.3 网格三实一标数据共享服务通过集成智慧城市三实一标基于网格数据共享服务，实现各部门业务系统 的数据初始化。2.3.4 全科网格责任平台打造全科网格全能社工，规定每个社区/村实现全能社工落实首问责任，并 将工作延伸到网格，集合条线信息，本次建设主要实现条线业务数据融合，责 任考核落实。2.3.5 网格信

34、息汇聚平台有效地采集网格“三实”基础信息以及跨业务系统社会治安、安全生产、 公共安全、城市治理、矛盾纠纷、问题隐患、市场监管、综合执法、消防安全 网络舆情、社情民意、帮扶救助等动态信息，实现统一网格数据汇聚。2.3.6 网格服务请求平台实现全科网格跨业务应用工作服务请求，满足全科网格全服务配套支持。2.3.7 网格员薪资报酬平台网格员工资报酬，由乡镇（街道）负责各社区、社工工资福利待遇绩效考 核管理。2.3.8 网格员职能模型根据全科网格的工作职能，形成业务职能模型，与条线业务数据实现互补， 多维度塑造业务模型。2.3.9统一业务支撑平台应用支撑是整个平台建设的核心，应用支撑体系是用来支撑一般

35、应用的基础 平台，为多个应用系统提供统一的用户管理、权限认证、安全管理、资源管理、 数据管理等基础功能，基于平台构建的应用系统拥有良好的集成性、扩展性，拥 有更好的性能和安全，通过应用支撑平台可以构建和扩展新的应用，构建在软件 应用支撑平台上的应用拥有更强的生命力，能够满足后续应用系统扩展和变化的 需要。包含系统平台的统一身份认证、权限分配、系统日志、数据交换系统、安 全平台等核心内容建设。2.3.9.1统一身份认证采用电子政务系统统一身份认证体系，进行整合用户身份，各业务子系统的 用户体系遵循智慧电子政务用户体系规范，与统一用户管理平台用户管理、应用 管理对接，实现统一认证，实现单点登录。2

36、.3.9.2工作流子系统工作流管理是用于实现对审批规则流程的功能，提供工作流引擎、可视化流 程设计工具等服务。流程设计器基于Web，具有流程多出口，流程快速设计、环 节功能定义、流程时限、预警等功能。2.3.9.3表单管理子系统表单管理支持各类不同浏览器版本的表单客户端设计工具，支持拖拽式操 作，设计所见即所得，提供多种表单模板机制，快速构建表单应用，无需停止服 务即可更新表单填写界面。实现表单的统一监控、保存、展示及相应的管理。由 表单引擎和表单可视化设计工具组成，提供可视化的表单设计器，支持多页（TAB页），支 持动态行，支持HTML的基本编辑功能，包括文本的查找、字体颜色的设置、位置的设

37、置、 表格的插入、复制粘贴、撤销等。第三章 组织保障建立由全科网格系统建设项目领导小组，领导小组由信息化工作分管领导任 组长，信息化建设管理职能处室负责人任副组长，各相关职能处室人员共同组成 小组。小组全面负责此项目的调研、审报、建设、验收等全过程的工作，确认本 次项目的顺利实施。拟聘请由计算机、社会治理及电子政务方面专家（3-5 人）组成顾问小组， 向项目领导小组提供有关项目运作、开发管理、软件工程等方面的建议和帮助协助指导项目建设。第四章 实施进度计划序号阶段任务时间安排1方案设计与规划分析、调研、规划、设计等。1个月2软件开发及测试主要包括建设系统开发、测 试、集成等。2个月3系统迁移和对接主要实现系统迁移和对接。1个月4推广和培训项目线上、线下推广及项目培 训。10日第五章 项目预算5.1 总投资预算总投资： XX 万元