序言：寫作是分享個人見解和探索未知領域的橋梁，我們為您精選了8篇的電子政務系統論文樣本，期待這些樣本能夠為您提供豐富的參考和啟發，請盡情閱讀。

第1篇

    圖3-3“工業年”活動信息實體圖

    圖3-4 新聞信息實體圖

    圖3-5 公告信息實體圖

    圖3-6調查欄信息實體圖

    圖3-7 用戶信息實體圖

    圖3-8 管理員信息實體圖

    3.3.4 數據庫設計

    一個實體型轉換為一個關系模式的集合。實體的屬性就是關系的屬性,實體的碼就是關系的碼。

    對于實體間的聯系則有以下不同的情況:

    (1)一個1:1聯系可以轉換為一個獨立的關系模式,也可以與任意一端對應的關系模式合并。

    (2)一個1:N聯系可以轉換為一個獨立的關系模式,也可以與N端對應的關系模式合并。

    (3)一個M:N聯系轉換為一個關系模式,與該聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性,而關系的碼為各實體碼的組合。

    (4)三個或三個以上實體間的一個多元聯系可以轉換為一個關系模式,與該多元聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性,而關系的碼為各實體碼的組合。 3.3.5 數據庫表設計

    (1)管理員信息表如表3-1所示。

    表3-1 管理員信息表

    (2)新聞信息表如表3-2所示。

    表3-2 新聞信息表

    (3)調查統計表如表3-3所示。

    表3-3 調查統計信息表

    3.4 網站風格設計

    (1)logo設計和說明

    政府網站的標志,相當于商業網站的logo,但一般多為國徽或政府名稱。政府的標識體現著政府的莊嚴與權威,不能像企業的標識那樣帶有太多的感性色彩。因此本政府網站將國徽和政府名稱想結合,體現了政府網站的特殊性,如圖3-9所示。

    圖 3-9 Logo設計圖

    (2)色彩搭配

    色彩的運用上,政府網站的色調應以沉穩、柔和、較暗的中性色為主,不宜太眩目。本網站采用白色和淡藍色為網站整體基調,體現的政府網站的莊重、威嚴但不失親切柔和。

第2篇

經過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