博文谷

位置:首頁 > 實用範文 > 論文

基於協同辦公的會議管理系統設計系統分析的論文

論文9.93K

隨着協同辦公系統的應用,企業和政府部門在開會的效率以及協同上提出了新的需求,會議管理系統也要求能夠實現在人員以及資源上的協同。協同辦公系統能夠消除“資訊孤島”[1][2],加強部門、人員之間的交流[3],整合優化審批流程。而基於協同辦公的會議管理系統則需要充分繼承協同辦公系統的優點。

基於協同辦公的會議管理系統設計系統分析的論文

基於此,設計並實現了本會議管理系統,其具有以下特點:1)與協同辦公系統的個人日程模組進行了集成,在會議報名時自動同步個人日程;2)與短信發送平臺集成,能夠根據報名時同步的個人日程自動發送短信進行參會提醒;3)與RTX(企業即時通訊系統)系統集成,能夠根據報名時同步的個人日程自動發送RTX資訊進行參會提醒;4)與CMS(內容管理系統)系統進行了集成,能夠直接透過會議系統在CMS系統發佈會議通知,使用戶能夠在CMS系統進行會議報名,報名數據同步並儲存在會議系統;5)實現了與其他各系統之間數據共享與協同,如:會議審批的待辦能夠在門戶系統顯示,與其他系統單點登入等等;6)能夠高效率、低成本地將會議系統的申請和審批流程進行了重組和優化。

2 系統分析和設計

2.1 設計原則

2.1.1 開放性原則

系統開放各種應用接口,以方便與其他應用系統進行數據交換,便於系統未來的擴展。

2.1.2 實用性/易用性原則

本系統完全使用B/S結構,系統介面應簡單並清晰,容易操作,使用戶能夠輕易地上手使用。

2.1.3 先進性原則

採用業界公認的先進和標準的軟件技術,符合資訊技術發展的未來趨勢,保證系統在可預見的階段內有相當強大的生命力,包括技術的先進性和架構的先進性。

2.1.4 可靠性/穩定性原則

基於成熟的系統平臺和技術進行開發,並可根據用戶的實際應用需求進行相應的配置和調整,從而保證系統的穩定、可靠。

2.1.5 容錯性原則

系統應具有檢錯、糾錯能力,具有完善的備份措施。在一個系統服務器出現故障時,能夠在較短的時間內恢復執行。

2.1.6 擴展性原則

系統採用基於B/S模式的三層體系結構及鬆散耦合的插件技術,無須對系統的體系結構做較大的改變即可實現功能擴展。

2.1.7 安全性原則

安全性是系統設計的關鍵,系統設計時應首先梳理系統安全體系,確保系統安全,並透過設定不同的人員權限來實現系統的安全執行。

2.2系統技術架構

架構平臺是應用系統建設的`地基[4],強健的架構平臺爲系統的可擴展、可維護提供了基礎保障[5]。本會議系統基於成熟的協同辦公系統架構,並結合當今主流的、跨平臺、跨操作系統、可伸縮、分佈式的J2EE技術,按照面向服務的架構思想將分佈式的應用系統採用服務的方式集成到平臺上,形成底層應用支撐平臺,如圖1所示。

基於此底層支撐平臺,使會議系統更容易開發,不用擔心其成爲資訊孤島,並且能夠利用協同辦公系統提供的工作流引擎、表單引擎,使會議申請、會議紀要的審批能夠統一在協同辦公系統流轉並統一在協同辦公系統的待辦列表顯示。工作流引擎可以使會議系統的流程很靈活的進行配置。

支撐平臺向CMS系統、RTX系統、短信發送系統等外部系統提供統一的基於SOA的標準接口,同時也對內部各應用提供了接口,內部應用透過調用內部接口同外部各個系統通信。其具有完好的封裝性和鬆散的耦合性,使會議系統、CMS系統、RTX系統、短信發送系統及流程審批系統不但在邏輯上是獨立的,而且在數據上能夠共享、交互,這樣就既消除了資訊孤島,同時又互不干涉,具有良好的可擴展性和可維護性。

3 系統功能實現

本會議管理系統具有會議室管理、會議申請、會議紀要督辦、會議通知發佈、會議報名、同步個人日程、會議簽到等基本功能,如圖2所示。

3.1 會議室管理

會議室的管理包括會議室的添加、修改、刪除、查詢會議室,會議室的使用情況。

在會議申請的時候能夠讀取會議室的使用情況,並能將申請情況數據儲存進數據庫。在選擇會議室的時候,自動過濾掉在該時間段使用以及不可使用的會議室,同時,在申請成功後,該段時間自動添加到會議室使用情況列表裏。

3.2 會議申請

會議申請爲本系統的核心,會議申請被審覈透過或者被主要領導審覈透過後即可進行發佈會議通知、會議報名、會議簽到和會議紀要督辦等操作。其基於協同辦公的表單引擎和工作流引擎,可以透過配置很方便地實現和編輯表單和審批流程。

會議申請表單上的項目包括:會議名稱、會議類別(即會議形式,包括:普通會議、視頻會議和電話會議)、申請時間、召開時間、結束時間、是否爲多部門會議(四個部門以上)、是否發佈會議通知,是否需要會議報名、召開地點、報名截止時間、會議目的和主要內容、臺籤內容、大屏幕內容、大屏幕發佈開始時間、大屏幕發佈結束時間、部門(自動獲取申請人部門)、聯繫人(自動獲取申請人)、聯繫電話、部門負責人意見、辦公室意見、主管領導意見、備註。

會議申請的審批流程如圖3所示。

3.3 會議紀要督辦

會議申請審覈透過後,可以啓動本流程。本流程也是基於協同辦公的表單引擎和工作流引擎,透過配置而實現。

會議紀要督辦單表單項目:會議名稱(從會議申請單映射)、召開時間(從會議申請單映射)、結束時間(從會議申請單映射)、會議紀要標題(手輸)、經辦人(自動取得當前登入用戶)、擬稿時間(自動獲取當前服務器時間)、電話(手輸)、處(室)審覈、辦公室審覈、局領導意見、主辦部門意見、協辦部門意見、辦公室主任意見、備註。

會議紀要督辦的審批流程如圖4所示:

3.4 會議通知發佈

會議申請透過後,會自動走一個會議通知發佈的審批流程,審批透過後系統會自動和CMS系統進行數據交互,在CMS系統發佈會議通知。

3.5 會議報名

會議通知發佈後用戶即可在CMS系統進行會議報名操作,報名數據儲存在會議管理系統。具有會議管理權限的人員能夠檢視報名情況,並可將報名情況匯出和打印。

3.6 同步個人日程

會議報名成功後系統會根據會議的時間安排自動同步個人日程。同步日程後,系統會在開會前自動透過RTX系統和短信系統對會議報名者進行參會提醒,以免忘記參加。

3.7 會議簽到