<nav id="w0g0m"><code id="w0g0m"></code></nav>
  • <xmp id="w0g0m">
    <xmp id="w0g0m"><nav id="w0g0m"></nav><menu id="w0g0m"><strong id="w0g0m"></strong></menu>
  • <xmp id="w0g0m">
  • <nav id="w0g0m"></nav>
    <menu id="w0g0m"><menu id="w0g0m"></menu></menu>
    1. 網站地圖
    2. 設為首頁
    3. 關于我們
    ?

    職業介紹代征信息管理系統的設計與實現

    發布時間:2023-07-17 14:36
    目錄
    摘要 I
    ABSTRACT I
    第一章 緒論 1
    1.1研究背景 1
    1.2 研究的意義 2
    1.3 國內外發展動態 2
    1.3.1 國外社會保險動態 3
    1.3.2國內研究動態 3
    1.4 陜西省社會保險信息化建設情況 4
    1.4.1陜西省社會保險基本概況 5
    1.4.2陜西省社會保險信息化基本情況 5
    1.5 課題的來源和論文研究內容 6
    1.5.1課題的來源 6
    1.5.2 研究內容 6
    1.6 本文的組織結構 7
    第二章 系統需求分析 9
    2.1 系統建設目標 9
    2.2 系統業務需求 9
    2.2.1跨部門協同 9
    2.2.2跨區域通辦 9
    2.3 系統功能性需求 11
    2.3.1系統主要使用者 11
    2.3.2基本信息管理 12
    2.3.3繳費核定管理 13
    2.3.4信息查詢管理 15
    2.3.5 綜合管理 15
    2.4 系統非功能性需求 16
    2.4.1 對性能規定 16
    2.4.2 數據管理能力要求 17
    2.4.3故障處理要求 17
    2.4.4其他專門要求 17
    2.5 系統接口實現 18
    第三章 系統架構設計 19
    3.1 系統設計環境 19
    3.1.1開發環境 19
    3.1.2 運行環境 19
    3.2 系統架構設計 19
    3.2.1 系統總體架構介紹 20
    3.2.2系統技術架構 22
    3.2.3系統架構特點 22
    3.3 系統設計核心 23
    3.3.1MVC 框架模式和 Strusts 框架模式 23
    3.3.1.1MVC 框架模式 23
    3.3.1.2Struts 框架模式 25
    3.3.2Struts 對 MVC 框架的支持 25
    3.4 應用中間件及服務 26
    3.4.1WebLogic 優勢 26
    3.4.2WebLogic 架構 26
    3.4.3WebLogic 服務 27
    3.5 繳費核定算法 27
    第四章 系統詳細設計 29
    4.1 系統的建模 29
    4.1.1靜態結構設計圖 29
    4.1.2對象關系設計圖 32
    4.1.3 動態結構設計圖 32
    4.2系統模塊功能設計 33
    4.2.1 基礎信息 34
    4.2.2 繳費核定 35
    4.2.3 信息查詢 36
    4.2.4 系統管理 36
    4.3系統數據庫設計 37
    4.3.1數據庫設計原則 37
    4.3.2數據庫設計規范 38
    4.3.3數據一體化和分類設計 38
    4.3.4 數據表設計 39
    4.3.5數據庫性能設計 41
    第五章 系統實現與測試 42
    5.1 系統總體實現 42
    5.2 系統各功能模塊實現 42
    5.2.1 基礎信息管理實現 43
    5.2.2繳費核定實現 43
    5.2.3信息查詢實現 44
    5.2.4系統管理實現 44
    5.3 系統配置及軟件 45
    5.3.1服務器軟件項 45
    5.3.2測試機軟件項 45
    5.3.3 測試工具 45
    5.3.4測試設備軟件設置 45
    5.4 硬件及固件項 46
    5.4.1 網絡環境 46
    5.4.2 硬件資源 47
    5.5測試說明 47
    5.5.1個人管理功能 47
    5.5.2單位管理功能 48
    5.5.3繳費核定功能 49
    5.5.4系統管理功能 49
    5.6測試結果 50
    5.6.1功能測試結果 50
    5.6.2易用性測試結果 51
    5.6.3可維護測試結果 51
    5.7 評價 51
    5.7.1能力 51
    5.7.2 缺陷和限制 51
    5.7.3建議 52
    5.8 測試活動總結 52
    第六章 總結與展望 53
    6.1 本文研究總結 53
    6.2 未來工作展望 53
    致謝 55
    參考文獻 56
    第一章 緒論
    1.1研究背景
    社會保障制度是一項保障參保對象從出生到死亡全過程保險管理服務的制度,其權 利主體是從事參與國家管理的政府公益服務機構[1]。社會保險作為社會保障制度的一部分, 由專門的公益機構組織實施。這些機構從事我國公民生活保障的管理,國民收入的二次甚 至多次分配,當群眾暫時或永久性失去勞動能力或由于各種原因導致生活醫療困難時給 于一定程度的幫助,或是在參保人死亡后給予參保對象家人一定的生活保障[2]。為此,社 會保險的合理分配就顯得特別重要,縱然其由國家行政主體實施。
    我國的社會養老保險制度改革是從19 世紀拉開帷幕的,經歷了逐漸由企業職工養老 過渡為企業職工基本養老保險,逐步由公費醫療過渡為基本醫療保險的過程[3]。隨著我國 綜合國力的不斷提升,人民群眾物質生活的極大豐富和生活水平的不斷提高,同時也伴隨 著我國經濟結構的調整以及各項社會保險行政法律法規的逐步出臺和完善,在此后三十多 年時間里,我國的社會保障制度日趨完善,社會保險事業發展日趨迅猛,社會保險種類不 斷健全,參保人群的數量更是逐年增多,社會保險信息量和需求也急劇增加。側面來看, 這些對社會保險業務的管理,尤其對人性化、科學化的社會保險服務提出了越來越高的新 要求[4]。
    2003 年底,國務院有關部門就原勞動和社會保障部提出的信息化建設項目給予批復, 同意全國勞動保障信息化建設項目立項。自此,“十二金”工程之一的“金保工程”全國 統一立項,其建設的初衷就是要進一步加快我國社會保障信息化建設步伐,提升人民群眾 社會保障幸福指數,豐富社會保障工作形式和手段。此項工程被國務院列為國家電子政務 重點工程,同時也為我國全面開展人社信息化奠定了堅實有力的政策保障和制度基礎。具 體來說,就是通過建立中、省、市、縣、鄉鎮五級社會保障數據中心,實現生產區、交換 區和決策區三個邏輯工作區。在整個網絡環境搭建的過程中,首先選擇五級安全高效的網 絡系統,包括連接中、省兩級的全國主干廣域網,連接省、市兩級的省級主干廣域網,以 及市域網絡中,以市級數據中心為節點,經過多級鏈路,最終延伸到各級經辦窗口,定點 醫療機構、郵局、銀行、地稅等相關單位。
    截至目前,我國的社會保險信息化工作已開展近 40 余年,期間在各部門的通力協作 下,做了大量的工作,也取得了一些成績。比如,先后建立了部分廣域網、局域網,開發 了養老、醫療、失業、工傷、生育等保險信息系統,也實現了勞動就業應用軟件的開發與 普及,為各項業務數據整合,為各項業務管理服務的標準化、規范化、高效化建設起到了 重要基礎性作用。可是,隨著“金保二期”規劃的提出和實施,很多地方的建設實際與“金 保二期”的建設要求,與構建快速高效便民的服務要求相比,與“讓群眾少跑路,讓信息多 跑路”的倡議相比,無論在管理模式、管理手段、技術架構,還是在服務理念、服務水平 和服務方法,甚至在硬件環境上均存在著巨大差距[5]。
    當前,陜西省省本級,尤其是西安、寶雞、咸陽、延安等地的自由職業者都是在職介 中心繳費,征繳地點相對集中、經辦服務窗口有限致使征繳效率不高,影響了自由職業者 對職介代征的整體滿意度。為促進養老保險經辦機構實時掌握職介中心的基金征繳,規避 職介代征機構“滯押”社會保險基金情況的發生,受省職介中心委托,特開發陜西省職介 代征信息管理系統。該系統在主要業務處理環節上,繼承了原勞動部核心三版平臺需求分 析報告和陜西省城鎮職工養老保險信息管理系統的規范和流程,提升了服務能力和效率, 防止了職介代征機構“滯留”社保基金情況的發生,實現了征繳基金的安全[6]。
    1.2研究的意義
    人類在發展繁衍過程中,對老、弱、病、殘等弱勢群體的保護首先是由家庭主體來承 擔的。科技的不斷發展伴隨著生產力的不斷提升,在這個過程中,國家經濟實力得到了不 斷增強,同時人民群眾物質生產資料也得到了極大豐富[7]。在我國社會發展過程中,我們 的社會保障、社會救助、社會福利體系先后不斷完善,為的就是不斷滿足人民群眾日益增 長的物質需要,使普通百姓能夠過上更加幸福美好的生活。而職介代征信息管理系統是針 對自由職業者,方便其參保登記、繳費及保費領取,使其像城鎮職工一樣有享有參與繳納 社會保險的平等權利的系統。從另外一個方面來看,對自由職業者更好的享受國家社會保 險紅利、體現國家公平具有重要意義[8]。
    在十九大報告中,習近平總書記闡述了新時期人民的主要矛盾,他要求:要始終堅持 以人民為中心的發展思想。人社部門作為社會保障的主要職責部門,更應該積極貫徹落實 國家“十三五”規劃綱要中提出的有關“實施全民參保計劃,基本實現法定人員“全覆蓋” 的部署及要求,將其不折不扣的落到實處。隨著社會保險政策的不斷完善以及信息技術的 飛速發展,陜西省人社系統的各級經辦機構也對人社信息化建設提出了更高的需求。尤其 對職介中心來說,方便職業介紹機構管理基金征繳,方便靈活就業人員參保繳費,促進養 老保險經辦機構實時掌握職業介紹指導中心的基金征繳,規避職業介紹代征機構“滯押” 社會保險基金情況的發生,依托先進的互聯網技術,更好的服務自由職業者和經辦機構, 防止基金發生危險就顯得格外重要[9][10]。
    1.3國內外發展動態
    一般來說,不同國家社會保險的含義和服務范圍也會不同。這主要與各國的政治經濟 制度息息相關,也與當地的社會文化、風俗習慣等因素相關[11]。因此,就全世界而言,不 同國家的政治經濟制度、社會文化背景、風俗習慣決定了各自不同的社會保險體系。但無 論是什么層級的國家,無論是發展中國家或是發達國家,他們有個基本的核心是不變的, 那就是始終本著為群眾服務的宗旨,也因此他們制度的設定會盡可能多的涵蓋養老、醫療、 工傷、失業、生育等方面,制度落實則會更多的照顧大多數人的利益,基本實現從低層次 滿足到更高層次滿足的全覆蓋[12]。
    1.3.1國外社會保險動態
    世界各國,由于政治經濟制度、社會文化、風俗習慣等的不同和差異,彼此之間工作 習慣、生活方式、思考問題的出發點也存在著巨大的差異,順理成章,它們構成了不同的 社會保障體系。我們非常清楚“經濟基礎決定上層建筑”,顯然資金是一個國家解決民眾 福利最基礎、最根本的支撐保障,無論哪個國家,無論處在什么階段,無論以什么形式, 均需要以巨大的財力作為支撐,實現民眾福利保障。在國際上,美、德、法等多數發達國 家建立的是以繳費型社會保險為主體的全民保險制度。
    作為世界上第一個建立醫療保險制度的國家,德國實施醫療保險基金社會統籌是比 較早的。當前,借鑒德國這種由雇主和雇員共同繳納,政府酌情給于補貼模式的國家特別 多。德國醫療保險最顯著的特征是高替代率。德國的替代率基本保持在 70%。他們的職工 在退休后,可以按月領取養老金,而領取多少是有諸多條件的,比如原來工資的高低,參 保時間的長短等。因此,我們可以看出德國在“多繳多得”方面做得非常的完善,既保障 了養老金的充足,同時也保障了退休人員的待遇領取[13]。
    對于世界上最發達的國家——美國,它的養老保險制度已建立將近200 余年,經過長 期不斷的發展和完善,美國養老保險體系主要由三部分構成,涵蓋了政府、企業和個人。 作為第一支柱的政府主導、強制實施的社會養老保險制度是核心;作為第二支柱的企業主 導、雇主和雇員共同出資的企業補充年金計劃制度是補充;最后由個人負責、自愿參加個 人儲蓄養老的個人退休金計劃是調劑,或是非必須。他們相互補充,形成合力,就如同“鳥 之雙翼、車之雙輪”為退休人員提供多渠道、高可靠的養老保障。
    作為“亞洲四小龍”之一的新加坡,或許法律是保障個人醫療保險的最好保障,因為 法律強制要求個人消費基金的一部分必須用于醫療保險基金,也就是說全體公民一個不 能落下,要全員參保,并且要按照一定的比例繳納醫保基金。征繳比例占到工資總額的 60%, 雇主和雇員按照不同的比例繳納,雇主 28.5%,雇員 21.5%。同時還有中央統一調劑基金, 新加坡還設立中央公積金,分擔部分費用。與此同時,還撥款大力扶持信托基金,建立保 健信托基金制度,解決貧困國民支付費用。可以說,在新加坡,無論你從事什么工作,無 論你的職業是什么,無論是高級官員還是一般雇員都享受同樣的醫療保健服務,所有國民 都執行統一的醫療保健制度[14]。
    1.3.2國內研究動態
    歷經三十余載的發展,我國的社會保險無論是制度機制層面還是信息化技術手段支 撐的發展均成績斐然。雖然起步晚,但是發展迅速且效果良好,短短幾十年,便取得了非 常好的成績,社會保障體系雖然還未最終形成,但社保體系輪廓已經非常清晰,同時我們 也在結合自身實際不斷的發展和提高。畢竟我國仍然處在社會主義處級階段并長期處于 初級階段的基本國情沒有變,資源消耗大、人均分配少,工資收入參差不齊,貧富差距大, 社保基金支付壓力大仍然是困擾我們社保事業發展的主要問題。目前來看,我國充分借鑒 世界各國的先進經驗,先后已經建立了集養老、醫療、失業、生育、工傷等五險于一體的 社會保障體系[15]。
    具體來看,養老保險是為了幫助勞動者解決因法定年齡退休,或是因年老喪失勞動力 而建立的一種保障基本生活的社會保險制度。基本保障、企業參與、個人儲蓄以及商業保 險共同溝成了我國的養老保險體系,全方位、多層次保障了群眾的養老安全,為我國養老 人員安穩幸福度過晚年生活提供了基本的經濟和制度保障。第一層是基本養老保險,也是 最基礎的保險。之所以說是基礎保險,原因是多方面的,主要是因為其由國家立法并帶有 強制性。其次,由國家、單位和個人三方共同承擔,由個人和單位雙方共同承擔保費繳納, 其對在職職工的各項權利起到了很好的保障[16]。最后,涉及面大,隨著我國逐漸步入老年 社會,領取養老保險基金的人員也會越來越多,對國家基金的整體支付能力和要求也會越 來越高,需要充足的資金來保障人民群眾的養老待遇和水平。
    醫療保險主要針對勞動者因疾病導致無法工作,從而造成經濟損失而建立的一種保 險制度。其繳費一般由單位和個人共同承擔。當參保人得病后,醫療保險機構,按照有關 要求和相關規定,分多次或一次性給于經濟補償。最終的目的,不僅僅是防止廣大人民群 眾“因病致貧”,同時還要更好地建立醫療健康體系保障,為民眾提供更優質、更便捷的 醫療保障體系和制度。我國自頒布實施《關于建立城鎮職工基本醫療保險制度的決定》以 來,失業保險制度就開始在全國范圍內開花結果。該項保險制度實現了對養老保險制度的 良好補充,且非常符合我國的國情。從當下國家快速推進跨地區異地就醫就可以看出來, 這是一個從無到有,從不完善到完善的過程[17]。
    失業保險是依據國家立法強制實施,在就業人員失去工作后,為其提供一定收入的保 險制度。具體來說,通過職工個人、用人單位繳納和國家財政補貼等渠道籌集資金,為失 業者提供強有力的保障,保護其在失業后有一定的收入,保障其短時間內不至于無法生活, 讓其可以維持基本生活,為他們下一階段工作提供良好的過度和幫助。失業保險主要針對 曾經就業并交納相關保險的人員,在失去工作后可以領取失業補貼。
    工傷保險因在工作或者前往工作途中,受到主觀或者客觀的意外傷害,導致無法繼續 從事生產生活,喪失勞動力甚至丟掉生命的情況下給于保障的制度。它主要依靠社會統籌 基金,由用人單位繳納一部分,個人承擔一部分,保障基金充盈。
    生育保險是廣大婦女同胞分娩期間保證正常收入的保護傘,是國家保障婦女權益,保 障在懷孕或分娩期的婦女勞動者暫時中斷勞動時,獲得一定的分娩補助和生活保障,同時 也獲得相應的補償的保險制度。生育保險的落實通過立法實現。生育津貼和生育醫療待遇 共同組成了我國的生育保險金[18]。
    1.4陜西省社會保險信息化建設情況
    陜西省社會保險信息化建設在全國屬于起步比較早,經過多年發展也取得了不錯的 成績。多年來,陜西省各級群眾的參保積極性越來越高,保險種類由單一險種拓展到多個 險種,參保人群的范圍由城鎮擴大到農村,由企業職工擴大到普通市民,可以說保障了群 眾的基本生活。伴隨著改革開放,市場經濟體制的逐步完善和建立,市場經濟結構的戰略 性調整和部署,形成了以公有制為主體、多種經濟形式并存的格局,為我們建設提供了重 要支撐。但傳統經濟條件下形成的社會保險制度還是存在諸多短板,比如險種種類不全、 覆蓋范圍不廣、管理不健全,缺乏立體統一的規章辦法。很顯然,進入新時代后,人民群 眾對社會保險的需求更加的迫切,當下的服務水平和能力已遠不能滿足人民群眾的需求, 尤其是針對自由職業者的服務已經遠遠不能滿足。
    1.4.1陜西省社會保險基本概況
    針對當下我國社會保險和信息化建設發展實際,陜西省人力資源和社會保障廳緊跟時 代潮流,緊盯“互聯網+政務服務”建設目標和群眾需要,自始至終把信息化高水平發展, 高起點規劃作為各項業務工作開展的先決考慮因素和條件。經過三年左右的集中建設期, 陜西省在全國已率先實現了城鎮職工養老保險的全省統籌。
    全省有將近2900 萬人參加社會保險,涵蓋養老、醫療、工傷、生育等,參保面積覆 蓋全省 12 個地市,100 多個區縣,實現了參保地域全省全覆蓋;同時,參保人員涵蓋機 關干部、企事業單位、下崗職工、在校學生、農村居民等,實現了參保行業的全覆蓋。唯 獨欠缺靈活就業人員,缺少針對他們的征收體系和保障制度,也缺少專業的信息系統。目 前,陜西省搭建了以養老、醫療、失業、工傷和生育為支撐的社保信息系統平臺,尤其養 老保險、失業保險、工傷保險實現了全省的統籌,各個險種均積累了大量的數據信息,初 步實現部分系統數據的“省集中”。但橫向之間各個險種沒有任何數據信息交換,各類數據 之間“各自為政,毫無關聯”,與相關部門“數據省級集中”的要求,與群眾的實際期盼還 存在著較大的差距,尤其是針對城鎮靈活就業人員的養老保險保費征繳,雖有政策,但繳 納途徑和方式單一。
    伴隨著改革深入推進,全省養老保險涵蓋人員范圍越來越廣,從起初單一的普通群眾、 企業事業單位干部職工,擴展到現在的被征地農民、軍轉干部、自由職業者、拆遷補償者 及特殊工種人員等。
    1.4.2陜西省社會保險信息化基本情況
    伴隨著改革的不斷推進和深入,人民群眾對社會保險信息系統的管理水平有了更高 的要求,這就從客觀上要求人社信息化發展需要不斷地提升,不斷地改進。唯有如此,我 們才能滿足人民群眾的基本需求。
    2016 年以來,陜西省人社信息化始終按照“完整、正確、統一、及時、安全”的總體 思路和“數據向上集中、服務向下延伸”的建設理念,緊緊圍繞業務、人群、功能、網絡 “四個全覆蓋”的實施目標,堅持“服務業務、服務群眾”,在各級人社部門的共同努力 下,以信息五級互聯、應用軟件基本統一、數據資源集中管理為主要特征的技術服務支撐 平臺已經初步形成。
    未來我們將始終以“統一規劃部署、統一標準規范、統一應用軟件、統一公共服務窗 口”為要求,堅持整體部署、省市協同、統籌做好各項信息化建設工作。力爭 3至 5年建 成一個數據資源集中統一、信息網絡安全可靠、業務經辦高效協同、公共服務全面便捷、 宏觀決策準確科學的信息平臺。
    1.5課題的來源和論文研究內容
    1.5.1課題的來源
    2016 年初,“互聯網+政務服務”成為國家戰略,國務院、人社部、各省政府陸續出臺 許多政策,推動各級政府、各級部門發展“互聯網+”業務。在不發展就落后的新形勢下, 為落實中央對陜西提出的“追趕超越”要求和目標,陜西省職業介紹信息化發展的當務之 急是認清當下“追趕超越”的基準和差距,并以此為契機,進行頂層設計、總體規劃,用 1 至 2 年時間逐步實現“追趕超越”目標,讓陜西省職業介紹實現經辦、監管、公共服務 及決策能力的全面提升,趕超全國先進地區。
    按照“互聯網+人社 2020”行動戰略和“信息化人社”發展要求,省委省政府、省人 力資源和社會保障廳非常重視社會保險信息化建設工作,省人社廳組織專業團隊、經過多 次討論,結合實際制定了陜西省社會保障信息化總體發展規劃。規劃之初就按照“統一規 劃、統一標準、統一管理,統一應用”的要求,實現了“業務對接無縫、信息共享無縫、 服務對象無縫、服務手段無縫”的信息化新常態。針對城鎮自由職業者養老保險繳費存在 的問題,依照省級單位和部分地市的新需求,在主要業務處理環節上,繼承了核心平臺三 板需求分析報告和陜西省城鎮職工養老保險信息管理系統的規范和流程,方便職業介紹 機構管理基金征繳,促進養老保險經辦機構實時掌握職業介紹中心的基金征繳,規避職業 介紹代征機構“滯押”社會保險基金的情況,特此開發職業介紹代征信息系統[19]。
    本課題受陜西省職業介紹技能鑒定中心的委托,經過充分的學習和分析,依據陜西實 際,根據需求進行設計開發,建立一個“職業介紹代征信息管理系統”,實現了靈活就業人 員的參保繳費,方便職介機構管理基金征繳,促進養老保險經辦機構實時掌握職介中心的 基金征繳,規避職介代征機構“滯押”社會保險基金情況發生。在整個項目進展過程中, 本人參與全部研究、設計和部分開發工作,特別對系統中職業介紹人員基金征繳功能模塊 進行了深入的研究[20]。
    1.5.2研究內容
    本課題基于對陜西省職業介紹機構的實際需求,采用先進的計算機和數據庫技術,依 托原勞動部核心三版平臺,為方便自由職業繳費,方便職介機構管理基金征繳,促進養老 保險經辦機構實時掌握職介中心的基金征繳,規避職介代征機構“滯押”社會保險基金情 況,對省職業介紹信息管理系統進行總體和統一的規劃、設計、開發[21]。
    主要內容如下:
    (1)緊密結合陜西省社會保險業務及其信息管理系統的發展現狀。結合各級職介機 構的需求和自由職業者繳費不方便的現實,充分與銀行、稅務等部門溝通,采用關鍵技術, 延長應用系統使用的生命周期。
    (2)真正實現自由職業者參保繳費的便利,實現“以人為本、記錄一生、管理一生、 服務一生”本系統是基于J2EE框架的B/S/S三層架構,應用服務器為WebLogic8.1 for HP UNIX,數據庫為ORACLE 10g for Aix,客戶端為IE8.0以上版本,JAVA VM為1.4.1以 上版本。
    (3) 職業介紹代征關系到千家萬戶的職業介紹機構和自由職業繳費者,關系到社會 保險公平運轉,關系到國家公平的體現。該系統的順利運行,對養老保險經辦機構實時掌 握職介中心的基金征繳,規避職介代征機構“滯押”社會保險基金的情況,對建立和諧社 會有非常重要積極的作用[22]。
    (4) 依托現有的城鎮職工養老保險平臺進行開發。該系統體系架構的實現模式充分 考慮了 J2EE。具體來說,體系架構時Server采用J2EE技術和MVC設計模式;客戶端主 要解決客戶界面交互,采用傳統Java編程語言實現界面交互,采用XML數據傳輸方法, 實現Client與Server的通信。數據庫采用先進的ORACLE數據倉儲技術,實現前端數據 展現。
    職介代征系統在開發之初就充分考慮陜西現有實際,在對現有城鎮職工養老保險管 理系統體系構架進行總體設計研究和分析的基礎上,利用半年左右完成項目系統各模塊功 能,且各項關鍵指標均在規定的范圍之內。目前,系統運行正常,滿足全省自由職業者、 經辦機構使用需求,同時也提高了各級的服務水平,得到大家一致好評。
    1.6本文的組織結構
    本文共六章。 第一章緒論闡述了項目的研究背景、意義、國內外研究動態和課題研究的相關內容。 闡明了系統使用的范圍和對象,同時也給全省自由職業者繳費和經辦機構帶來了便捷。
    第二章系統需求分析。從系統建設目標、系統業務需求、系統的功能性需求和非功能 性需求、接口實現等方面進行了詳細描述。對系統的基本信息、繳費核定、信息查詢和系 統管理等模塊進行了說明。
    第三章系統架構設計。描述了職業介紹代征系統的設計目標和原則,對系統的架構設 計及架構過程中使用的核心技術進行了簡單介紹。闡述了 MVC框架及Struts框架的相關 特點及優勢,同時也繳費核定的算法進行了描述。
    第四章系統詳細設計。對職業介紹代征信息管理系統的建模、功能模塊設計等進行了 描述。同時對數據庫設計的原則規范及一體化設計、分類設計進行了詳細描述。
    第五章系統實現與測試。對職業介紹代征信息管理系統的總體實現和各個子功能模 塊的實現進行了敘述。同時對系統測試的軟硬件環境、過程及結果進行了描述和簡單分析。
    第六章總結與展望。簡單描述了研究成果及意義,總結了職業介紹代征信息管理系統 的架構特點和適用范圍,同時也強調了開發過程中的不足之處,對下一步研究提出展望。
     
     
    第二章 系統需求分析
    陜西省職業介紹代征信息管理系統以集中式資源數據庫為基礎,實現了省級職業介 紹管理信息的登記、保費繳費、信息查詢、系統管理等功能,實現了業務經辦全程的信息 化、網絡化,同時支持與相關單位(企業、銀行、地稅、公安等部門)的信息交換。其主 要業務功能包括:基礎信息、繳費核定、信息查詢、系統管理四個功能。
    2.1系統建設目標
    系統建設最終實現的目標是為方便全省各級受理自由職業者繳費、方便職介機構管 理基金征繳,保障養老保險經辦機構實時掌握全省職介中心的基金征繳情況,規避職介代 征機構“滯押”社會保險基金這種不安全情況的發生。在提升各級各類相關業務經辦效率 的同時,實現對國家社保基金安全高效管理。
    2.2系統業務需求
    2.2.1跨部門協同
    與公安:建立基礎數據采集實時比對機制,實現基礎數據精準、實時采集。與民政: 建立死亡人員定期比對機制,防止養老保險基金多發,甚至出現冒領情況。與稅務:建立 社保、稅務、企業網上服務平臺三方共享信息協作平臺,提高業務經辦效率,避免經辦人 多跑路、讓數據多跑路。與銀行:建立金融管控平臺,實現基金收支業務高效運轉。與參 保單位:建立社企服務平臺,實現人員社保參保、人員異動、社會繳費及時申報。與人社 部:實現人員轉移、離退休人員異地退管、數據交換等信息共享。與社會養老企業實現退 休人員信息共享[23]。與各業務部門之間的關系如圖2-1 所示。
    職業介紹代征信息管理 系統 社會化管理機構)匚
    圖 2.1 職業介紹與相關機構信息共享
    Figure 2-1 Career Introduction Information Sharing Of Relevant Institutions
    2.2.2跨區域通辦
    實現“全省/全市業務通辦”,就是辦事人員無論在全省/全市哪個經辦機構辦事,“全 省/全市”所有經辦機構都可以受理。實行全省整體通辦是當下現實服務的需要,“讓辦事 人少跑路,最好不跑路,讓數據多跑路”是我們的奮斗目標,也是我們的具體措施,更是 是互聯網業務發展必然結果,盡早推行“全省/全市通辦”可提升政府形象,從技術上講, 限制全省業務通辦的主要難點是本地化特殊業務,通過實現受理和經辦分離,受理經辦機 構無需掌握具體業務細節,受理崗位采集辦事信息,通過網絡電子傳遞到參保地進行審核, 可以解決跨區經辦問題。當然考慮組織職能改革有一定時間,也可根據業務項目逐步開放, 邊試邊推,逐步實現系統內全業務覆蓋。全省通辦有兩種模式,一種是直接經辦,一種是 受理經辦,未來兩種方式都可能存在,對于全省/全市政策統一業務,可以直接經辦,對 于本地特色業務和需要審批業務,受理經辦機構只負責受理、反饋,不做審批和經辦,通 過工作流流轉到參保地或其他經辦機構辦理。業務辦理工作流程圖如圖 2-2所示。
    全省通辦業務模型
    辦事地(異地) 參保地 業務流轉地
    時辦結
    工作流通知
    乏理/反——: —[總 I作流反饋J審批/辦結
    受理/反饋* 工作流通知——
    〒作、疥曰犒 j翅
    叉坯/ ZX. kJA 丄作流反饋 審批/辦結
     
    圖 2.2 業務辦理工作流流轉圖
    Figure 2-2 Professional Workflow Chart
    業務流轉一般由參與代征代繳的經辦機構發起,當經辦機構的辦事人員發起請求時, 申請異地受理后,就會形成待辦事項,待辦事項自動分發為省會城市或是其他地市,辦事 結果以通知形式反饋給辦事人,或是形成事項自動分發給各經辦窗口。同時,依據相關規 定,自用工之日起 30日內,用人單位應該盡快為其職工申請辦理社會保險登記并申報繳 納社會保險費。在陜西省首次建立社會保險關系、未納入系統的人員需先進行人員參保登 記操作。新參保根據年齡分為三類:一般正常新參保,臨帳判別人員新參保,超齡人員新 參保。參保時支持單個人錄入和批量導入的;提供批量導入模版下載;可打印《陜西省城 鎮企業職工基本養老保險人員登記表》;支持業務辦理進度查詢;支持二級單位辦理該業 務;支持人與證件一致性識別認證。大陸職工可直接在網上服務平臺辦理;外國人或港澳 臺職工需到大廳窗口辦理;其他政策文件規定的特殊參保需到大廳辦理。具體辦理工作流 轉圖如圖2-3 所示。
     
    圖 2.3 省市業務分工工作流程圖
    Figure 2-3 Division Of Labor Between Proviences And Cities Flow Chart
     
    2.3系統功能性需求
    2.3.1系統主要使用者 通過建立統一的系統平臺,實現網絡管理安全,業務操作規范,及時采集各項數據, 不斷細化查詢分析內容,方便全省各級受理自由職業者繳費,方便職介機構管理基金征繳, 促進養老保險經辦機構實時掌握職介中心的基金征繳,規避職介代征機構“滯押”社會保 險基金[24]。作為系統的主要使用者,無論是經辦人還是代征代繳機構都可以很好的依據該 平臺實現靈活就業人員參保保費征繳。也就是說:職業介紹代征信息管理系統的核心作用 是實現自由職業者的繳費,方便其在任何地點、任何時間,以任何形式實現作為一個公民 的基本權利,進行社會保險的參保,實現個人權益保障。其主要功能包含基礎信息管理、 繳費核定管理、信息查詢管理及系統管理等模塊。各項大功能下實現了各自模塊數據的增 加、刪除、查詢,無論是繳費核定、還是信息查詢,均實現了各自的功能。同時,該系統 平臺依托于陜西省城鎮職工養老保險信息系統平臺和陜西省社會保險基金查詢分析系統 平臺實現了系統功能的架構,方便了自由職業者的保費政教,方便了經辦機構的繳費核對,
    保障了保費的安全,防止了基金“滯留”現象的發生。系統的主要業務及邊界如圖2-4 所
     
    示。
    圖 2-4 系統功能模塊及邊界圖
    Figure 2-4 System Function Module Diagram
    2.3.2基本信息管理 基本信息管理是整個系統的基礎模塊,為整個職業代征信息管理系統提供個人基礎 信息。其包含個人參保基本信息變更、登記,同時對參保人員保費征繳,暫停、恢復等
    功能進行了實現。實現了與參保人相關的一切數據的存儲、管理,極大的方便了繳費核
     
     
    Figure 2-5 Basic Information Management User Case
    基本信息管理時,首先是核心端進行職介用戶注冊,職介用戶通過系統進行登陸
    后,職介端實現業務經辦,個人新參保、基本信息變更、恢復繳費等操作均需要在核心
    系統進行審核。如果通過,則職介端數據生成結束操作,否則重新回到職介端進行業務 經辦,重新復核。基本信息管理業務流程圖如圖2-6 所示。
    核心端 進行職 介用戶 注冊
    (核心 段用 戶)
    圖 2-6 基本信息管理流程圖
    Figure 2-6 Basic Information Management Flow Chart
    2.3.3繳費核定管理 繳費核定主要涉及職業介紹機構和銀行機構。我們都知道,代理經辦機構在進行業 務辦理時,需要獨立面對每個參保人、自由職業者進行繳費核定,同時計算每個分支機 構、每個人某月某年應繳納費用總額,根據繳費核定的結果,生成相關數據并報送銀 行。作為社保部門征繳社保基金的代征窗口之一——銀行就顯得分外重要,因為有的保 費是直接到稅務部門進行核算并進入國庫的,而有的繳費是通過職介經辦機構進行代征 代繳,定期將繳納數據回盤給銀行,雙方核定無誤后再由銀行代繳到稅務部門,最后再 回到國庫。通過銀行再到稅務部門,代理機構的財務接到銀行的回單后(證實繳費已完 全進入社保基金帳戶),經辦機構要對代理機構的繳費信息進行核定結算,做到賬處理, 即記載代理機構的實際繳費情況,同時為養老人員劃撥賬戶。最后,根據基金的實際分 配結果,報財務部門按照各項基金做財務賬。繳費核定用例圖如圖2-7 所示。
     
     
    通過繳費核定管理業務流程圖,我們可以很清楚的看到繳費核定的全過程。當核心 端用戶通過職介系統進行登陸后,職介系統進行業務經辦,先進行個人繳費定,完后再 進行繳費核定匯總,在這個過程中先后完成了“結算”、“日結”、“到賬登記”、 “到賬處理”四個業務,代理機構結算完成后,最后代理機構再依據一定桂策進行分 配。繳費核定管理業務流程圖如圖 2-8所示。
     
    圖 2-8 繳費核定業務流程圖
    Figure 2-8 Payment Verification Flow Chart
    2.3.4信息查詢管理 信息查詢功能是職介系統的核心功能之一,該功能的設定可以輕松實現各類人員和機 構的信息查詢,做到各類信息準確無誤。信息查詢主要包括:個人信息、單位信息、繳費 信息等內容,對單位信息來講,可以實現單位繳費花名冊,單位基本信息,單位年度申報、 辭退人員、各項繳費臺賬、交接匯總信息查詢以及退休人員基本信息、離退休人員基本信 息查詢等功能。信息查詢管理用例圖如2-9 所示。
     
    圖 2-9 信息查詢管理用例圖
    Figure 2-9 Information Service User Case
     
    2.3.5綜合管理 綜合管理是建立在高效運行的系統之上,在實現個人和單位機構的全方位管理后,對 系統的高效運行提供了保障和依據。綜合管理也是職介系統的核心模塊之一。綜合管理就 是實現對系統權限進行全面綜合管理,綜合管理的參與者為系統管理員和業務經辦人員, 業務經辦人員包括各經辦機構工作人員和各級銀行代征部門。綜合管理模塊的主要功能 是實現下屬分支機構管理、分支機構用戶授權,人員轉移分支機構三項大功能,通過對這 些用戶和機構的高效便捷增加、分配、管理,實現各項管理業務的高效運轉,保障自由職 業者參保登記、繳費、待遇領取。可以說綜合管理是對職介系統使用者的一個整體管控。 系統管理用例圖如圖 2-10 所示。
     
     
     
    代理機構
    圖 2-10 綜合管理用例圖
    Figure 2-10 System Management User Case
    2.4系統非功能性需求
    2.4.1對性能規定
    根據行業經驗,職業代征信息管理系統從精準性、時效性和靈活性等三方面進行了具 體分析。
    精準性主要針對的是數據統計。依照現有的計算統計體制標準,我們依照實際使用原 則來確定數據的精準性。在職介代征信息系統中,各種類型數據指標精度要求如表 2-1 所 示。
    表 2-1 各種類型數據指標表
    Table 2-1 Various Types Of Data Index Tables
    數據類型 精度要求
    繳費基數
    單位繳費工資總額
    個人繳、付費金額
    單位繳、付費金額
    利息
    利率 小數點后四位。例如:0.0250 或 2.5%
    繳費比例 小數點后四位。例如:0.0065 或 0.65%
    時效性主要強調的是系統響應的時間。根據行業慣例,一般情況下系統可忍受的響 應時間在 6-8秒內,同時后臺主機及網絡的響應時間一般不超過整個交易時間的 50%。 但我們都清楚,不同的連接方式會導致不同的響應時間,從而出現承受時間與當初設定 的不一致。核心城市經辦服務大廳和業務代辦點的響應時間不同,可定義為兩級。一般 情況下可以將中心城市營業大廳響應時間設在6 秒內,業務代辦點及區縣業務經辦所的 響應時間設在8 秒內。依照數據量及最大原則,歷史性數據查詢、統計性操作的響應時 間可相應延長為20 秒左右。當所要求處理的數據量特別大時,響應時間可根據實際情況 特殊確定。
    靈活性就是需要考慮環境、軟件接口等方面的變化。當需求發生某些變化時,通過 合理的模塊劃分實現應用軟件對業務變更的靈活適應能力。職介代征信息系統設計時我 們考慮以下幾個方面因素變化:首先是運行環境的變化;其次是軟件接口的變化;最后 是精度和有效時限的變化。
    2.4.2數據管理能力要求
    考慮到參加各項社保事業的人數分布情況:以數量最大的養老保險人數(1300 萬) 為基準,再加上離退休人員數(200 萬),系統與參保人員有關的最大記錄數為 1500 萬,針對軟件的結構特點,我們知道基于城鎮職工養老保險信息管理系統的每個自然人 在系統中的記錄約為1MB,則所有參加各項社保事業人數的存儲容量(生產區、交換 區、決策區)為:1500*10000*l/1024/1024=14.3TB
    考慮到公共服務區也存放有關公共服務的數據和信息,預計到2020 年,全部數據約
    為5TB,則存儲陣列整體容量為14.3+5=19.3TB,考慮到系統冗余和糾錯的需要,要求整 體裸容量〉=20TB。
    2.4.3故障處理要求
    應用軟件在程序發生故障時,應該能夠準確清晰的提示出故障原因,在系統硬件和 軟件發生故障時,產品維修與維護如未能在規定的時間內完成,否則將會影響各項業務 的正常辦理,實現在維修、維護期間不影響自由職業者和經辦機構的的正常使用就顯得 格外重要。
    2.4.4其他專門要求 對輸入輸出各類數據類型,以及對媒體、格式、數值的范圍、精度等均要進行詳盡
    而細致的功能描述。系統設計時,我們最大限度滿足各類服務對象的使用習慣,針對其 習慣進行操作設定, WEB 頁面布局充分參考現有全省統一養老保險軟件,設置背景為淡 藍色,主操作頁面為藍灰結合的色調,給人以清爽的感覺。系統設計應易于維護、升 級,能夠運行于多種版本的操作系統平臺。
    2.5系統接口實現
    為了更好實現跨部門應用,實現信息的互通和共享,此次業務預留的接口主要包括: 與全省社保業務系統,與培訓機構,與技能鑒定部門的接口,同時系統還充分考慮銀 行、定點醫療機構、基層經辦機構和各級稅務經辦機構部門的接口開發。具體描述如 下:
    與銀行等金融部門的接口:由于當前社會保險經辦機構與金融部門沒有實現網絡互 聯,代發數據以文本文件、excel文件、xml文件方式通過軟盤方式與系統實現交互共 享共用。
    與定點醫療機構的接口:通過SOAP協議,采用SOA的技術框架,在網絡互聯的情況 下,實現與定點醫療機構的實時結算。
    基層經辦機構信息采集平臺接口分為網絡版與單機版。其中網絡版主要通過交換數 據庫與本系統交互;單機版以文本文件、 excel 文件、 xml 文件方式通過軟盤方式與系 統交互。
    與稅務部門的接口:由于當前社會保險經辦機構與地稅部門沒有實現網絡互聯,代 征數據以文本文件、 excel 文件、 xml 文件方式通過軟盤方式與系統交互。當前,隨著 國家社保征收劃轉統一改革工作的持續推進,人社部門正在打造與稅務部門的應用系 統。
    第三章 系統架構設計
    陜西省職業代征信息管理系統是一個覆蓋范圍廣、操作環節多、數據處理量大的社會 保險征繳應用系統。根據該系統的建設目標,最終需要實現集實用性、可靠性、安全性、 可擴充性、易維護性等于一體,以方便各級自由職業者和經辦機構快速高效征繳繳費為基 礎的系統。從整個系統的架構來看,多種關鍵和先進技術的應用,對系統最終實現各項功 能起到了舉足輕重的作用,同時優良的架構體系也為系統安全平穩運行奠定了基礎。例如, Struts技術、MVC框架協議等技術的采用。
    3.1系統設計環境
    陜西省職介代征信息管理系統基于原勞動和社會保障部的核心三版平臺的規范和流 程,面向全省職介機構的社會保險代征信息管理系統,系統以集中式資源數據庫為基礎, 最終目的是為了實現全省自由職業者的登記、繳費、信息查詢、系統管理等業務經辦全過 程的信息化、科學化,同時也可以實現與相關單位和部門(銀行、地稅、企業等)進行信 息交換。無論是操作系統或是輔助設計工具,還是運行環境,我們都進行了嚴格的測算和 設計,實現了硬件資源的最大化利用。
    3.1.1開發環境
    操作系統: WindowsXP
    數據庫: Oralce10g 以上
    設計輔助工具: Rose,PowerDesigner,Visio
    開發語言: Java,Jsp
    開發工具: JBuilder2006,UltraEdit10.0
    缺陷管理工具: TD8.0
    3.1.2運行環境
    本系統基于J2EE框架,以B/S/S三層架構進行程序開發,應用服務器為WebLogic8.1 for HP UNIX,數據庫為 ORACLElOg for Aix,客戶端為 IE8. 0 以上版本,JAVA VM 為 1.4.1 以上版本。
    3.2系統架構設計
    職介代征信息管理系統是在陜西省城鎮職工養老保險核心平臺總體架構框架下進行 設計開發的,而陜西省城鎮職工養老保險核心平臺又是基于原勞動部核心平臺三版
    (CorePlatFormV3.0)搭建,原平臺采用LEAF5體系架構,依托企業級應用框架(SLEAF) 進行總體設計開發,因此,職介代征信息管理系統也是基于原勞動部核心平臺三版搭建, 同樣也采用了 LEAF5框架進行總體架構設計。
    3.2.1系統總體架構介紹
    職介系統總體依據一般軟件架構的規范和標準,堅持面向多層級、多用戶的設計理念, 實現數據錄入、審核、查詢、匯總、上報等操作,主要依靠“金保業務專網”和電子政務 內網進行數據傳輸和業務經辦的信息管理系統。優良的系統架構設計方法為各功能的實 現和交互、其他相關系統之間良好的交互奠定了基礎。在架構之初,我們就統籌考慮系統 平臺、數據庫、業務對象等多方面的因素,使其實現結構合理,資源節約、經辦高效的應 用架構。其整體應用構架如圖 3-1所示。
     
     
    圖 3-1 系統應用架構圖
    Figure 3-1 System Application Architecture Diagram
    系統架構圖最底層是數據業務層、實現了對數據的各項操作,其次是數據中心,、最 上層是業務系統設計平臺,實現了單位、用戶等各個使用者的管理。業務人員和技術人員 對不同的問題有不同的理解,也會給出不同的解決方案。通過溝通協商,最終解決不同類 型、不同業務人員面臨的問題,實現業務高效經辦、數據高效傳輸。良好的系統交互,使 得從問題提交到問題反饋都變得更加順暢、高效。具體的問題提交如圖 3-2所示,問題反
     
    業務負責人員
    反饋信息
    f
    業務人員 A
    圖 3-3 問題反饋圖
    Figure 3-3 Issue Feedback Diagram
     
    3.2.2系統技術架構
    通過 LEAF 框架示意圖我們可以清晰的看到,本系統的體系架構嚴格參照了人社部要 求的相關技術標準,在 Server 端,充分學習參考 MVC 設計模式和 Struts 框架架構模式; 在Client端,采取較為傳統的編程設計語言J2EE,實現界面交互;Client端與Server端 的通信采用XML數據傳輸方法泅。因為XML本身是基于HTTP和SOAP協議的可擴展標記 語言,非常適合Web傳輸。其構架圖如圖3-4所示。
    Application layer (應用層)
     
    J2EE平臺的系統級服務(JTA、JMS、JNDI等)
    Social insurance enterprise application framework( SIEAF)
    圖 3-4 Leaf 框架示意圖
    Figure 3-4 Leaf Framework Sketch Map
    具體來看總體架構可以從底、中、上三層進行理解:
    對底層而言,最底層采用J2EE進行架構,實現了系統基本服務,比如基本事物、安全。
    對中間層而言,作為系統的核心框架之一,一般我們把它分為框架服務層和框架控制 層,且每層均有其不同的功能[26]。比如:框架服務層主要是為系統提供多應用的服務,框 架控制層主要控制系統的處理流程。對邏輯層而言,專門處理應用邏輯。
    對上層而言,用戶可以通過統一的門戶進入系統,實現各項功能的操作,簡而言之 就是應用系統操作界面。
    3.2.3系統架構特點
    通過分析LEAF框架結構,我們可以總結出職業代征信息管理系統的框架特點有以下 幾方面:
    一是較高的運行效率。良好的效率離不開高并發下的高效率運行和處理,離不開批 量數據處理的高效率和低能耗,還離不開應用系統的良好可擴展性,更離不開應用軟件 的優質的可擴展性。所以說,運行效率的高低是與系統平臺和軟件本身的可擴展性息息 相關的[27]。
    二是較好的可移植性。企業級的安全服務需要保障數據傳輸過程中的安全,做到數 據加密傳輸,做到對所有用戶的各項權限進行認證,同時做到專業的日志服務登記,比 如操作日志、登錄日志等,做到全方位監管和控制。
    三是規范的入口接口。為了提高系統的可用性,在統一接口規范的同時統一入口標
    準,實現與外界其他系統的高效交互調用[28]。
    3.3系統設計核心
    為了節省時間,提高效率,方便經辦,陜西省職介代征信息管理系統巧妙結合了 MVC框 架和Strusts框架模式,構建了一個統一的數據資源庫。實現對這些模式的重復使用和調 用,系統設計具備良好的延展性、替代性,在不同的場合、不同的條件下,實現單一模式 的來回變化,同時實現設計模式的簡化。
    3.3. 1MVC框架模式和Strusts框架模式
    3.3.1.1MVC 框架模式
    MVC 作為一種框架模式,它在交互式系統平臺設計中體現出其強大的優勢和作用。大 多數情況下,我們將其應用到映射傳統輸入、處理和輸出,尤其是在一個邏輯的圖形化用 戶界面結構之中[29]。
    MVC 模式的所有框架,可以單獨處理,更不需要其他的協作。模型、視圖、控制器作 為它的三個核心部件,可以獨立運行處理,也可各自處理著各自的目標任務。有一個最顯 著的特點就是代碼復用[30]。代碼復用最直接的體現就是通過通用模塊組合成庫或工具集, 歸集管理,實現多場合應用。特別是應用框架的復用,其核心就是對專用領域的重要性實 現利用[31]。
    陜西省職介代征信息管理系統在設計之初就充分考慮了框架設計可能會遇到的各種 困難,充分考慮模型、視圖、控制器業務處理流程優化,從起始點等待用戶輸入開始,途 經人機交互抵達控制器,控制器又將用戶的數據和指令傳遞給業務模型,緊接著又進行業 務邏輯判斷,實現對數據庫的存取,根據業務邏輯選擇不同的視圖,再次通過人機交互將 結果反饋給用戶。整個過程,控制器、模型、視圖以及數據庫之間的關系可以用下圖體現, 如圖3-5所示。
     
     
    圖 3-5 模型-視圖-控制器業務處理流程
    Figure 3-5 Transaction Processing Of Mvc
    相應的我們關于模型、控制器、視圖三者之間的關系也就有了比較清晰的理解,他們 之間的關系我們用圖 3-6所示。
     
    圖 3-6 模型-視圖-控制器關系圖
    Figure 3-6 Relation Diagrm Of Mvc
    由于在系統設計之初,我們采用了 JAVA設計語言,在考慮應用MVC框架時,我們就 充分考慮了將Java Web應用于MVC框架,實現Java Web和MVC的有效結合[32]。下面我 們分別從視圖、模型和控制器三方面來進行說明:
    首先是視圖。即用戶看到并與之交互的界面。無論是新舊Web應用,均對HTML元素 組成的界面和視圖界面有著重要影響,可以說兩者息息相關。比如現有的 Adobe Flash 等 標識語言。
    其次是模型。主要用來表示企業數據和業務規則。對J2EE平臺而言,JavaBean可以既 方便快捷的完成模型這部分功能,又實現業務邏輯和數據結構的處理。模型可以決定數據 返回的類型,并為視圖提供數據。
    最后是控制器。我們都清楚控制器本身是不能輸出任何東西的。當用戶輸入和調用模 型及視圖時,選擇恰當的時機對超鏈接和處理表單進行操作,從而實現高效處理[33]。
    3.3.1.2Struts 框架模式
    對 Strusts 框架而言,一般分為兩個框架模型;系統內部本身是一個框架,另外一個 是事務邏輯框架,用來改變事物操作[34]。擁有狀態信息的bean調用方法使我們可以很好 的完成各種操作[35]。在 Struts 中,基本組建 ActionServlet 類中的實例 Servlet 是很關 鍵的[36]。具體如圖 3-7 所示。
     
    圖 3-7 Struts 框架體系結構圖
    Figure 3-7 Architecture Diagrm Of Struta
     
    3.3.2Struts對MVC框架的支持
    基于 MVC 的 Web 系統在構建時是非常復雜的,因此在實現時需要一個更加高效率、更 加成熟,具有事半功倍效果的框架[37]。
    對控制器而言,我們都非常清楚Action Servlet接收Struts中所有用戶的所有請求 時, 根據請求的不同樣式一一查找文中相應的執行。依據執行情況,再執行相應的控制器 功能,同時快速調用后臺的模型,從而完成業務邏輯調用,最終實現用戶請求[38]。
    對視圖而言,當使用一個 Action Form 組件時,視圖層就開始進入工作狀態,相應的 組件就被劃分到視圖層。此時,用戶所提交的各項請求數據就被打包,形成一個Bean對 象。比如JavaBeans作為一個可以復用軟件模型,它在某個容器中運行,提供具體的操作 性能。在設計中,JavaBeans按照屬性的不同作用又細分為四類:Simple, Index, Bound 與Cons trained屬性。Java應用程序在運行時,最終用戶也可以通過JavaBeans所提供 的屬性存取方法(set方法和get方法)修改JavaBeans組件的屬性[39]。
    對模型而言,Struts框架應用程序對模型部分確實沒有太多的規定和要求,大多數情 況下,我們優先采用 EJB 映射工具實現模型組件。有的時候,我們也采用其他組件(如 Hibernate)來實現,方法并不唯一[40]。
    對Struts的配置本身而言,一般情況下Struts的配置文件主要通過Action Servlet 來處理,同時也通過Action Servlet來轉發用戶請求[41]。此時,我們需要描述用戶請求 路徑和 Action 映射關系的一些配置信息,而每一個 Action 的映射信息都可以通過一個 元素本身在 Struts 中進行配置,實現預期要求,而這些配置信息絕大部分都存儲在特定 的 XML 文件中[42]。
    3.4應用中間件及服務
    Webserver 具有解析、發布網頁等功能,依據 Java 進行開發。目前 WebLogic 最新版 本為Oraccle WebLogic Server 12c (12.1.3)。它擁有處理關鍵Web應用系統問題所需 要的性能,為個性化應用部署提供了完善的解決方案。
    3.4.1WebLogic 優勢
    它的優勢集中體現在標準化、易拓展、高可靠等方面。它支持業務內的多標準,實現 了 web 應用系統的簡便實施;同時還實現了動態網頁和 EJB 組建的集群;它的靈活、可 靠、易擴展等性能已經歷數不勝數的驗證。
    3.4.2WebLogic 架構
    依托集群技術, WebLogic 實現了網頁和 EJB 的組建集群,架構具有高可移植性和可 擴展性。
    3.4.3WebLogic 服務
    WebLogic 服務涵蓋最少兩方面,從部署到應用、從架構到安全都體現出了服務功能 的穩定性和多樣性。它可以實現用戶的驗證和授權通過安全套階層體現;實現多個服務器 組成的集群,具有高可用性,各服務器之間可以實現負載均衡和高容錯能力;實現遠程方 法調用;實現基于J2EE標準編寫的代碼等嗣。
    3.5繳費核定算法
    針對自由職業者生活地點不固定,工作單位和性質不固定,年齡、受教育程度參差不 齊,其所在各地區經濟發展水平也存在差異等情況,我們依托人社部勞動核心平臺三版設 計,參考陜西省城鎮職工養老保險繳費核定的重要核定因子,結合靈活就業人員實際設定 了職業介紹繳費核定的參數和因子,本著“多繳多得、分層次征繳”原則,根據退休時年 齡的不同,參考不同的計發月數,保證計發月數隨著年齡的增大而減小。
    一般情況下,繳費標準基數為月工資除以全省平均工資。每年的繳費標準有很多檔次,
    0.4-1.0,每個檔次對應的金額也不同。繳費比例一般我們按照 20%測算。除特定的各項 參數外,我們統籌考慮自由職業者個人收入總額,考慮全省經濟發展水平不平衡、不充分 問題,對全省各地進行區域劃分,同時對繳費者的年齡、性別、學歷、工作年限等也納入 了核定范圍。比如:
    (1)收入總額。凡年收入低于省社平工資 30%的,按30%核定繳費基數;高于省社平 工資 30%不足 60%的,按年收入的 50%核定繳費基數;高于省社評工資 60%的不足 80%的, 按照不高于年收入的 60%核定繳費基數;如果年收入高于社平工資 80%的,按照不高于年 收入的 80%核定繳費基數。但是最高不得高于省社平工資的 300%。
    (2)繳納區域。按照陜西各地經濟水平發展能力,將全省分為四個大區域:西安為一 類區,榆林、咸陽、寶雞、渭南、漢中、延安為二類地區,安康、商洛、銅川、楊凌為三 類區,同時全省所有貧困區縣為四類區域,要求一類區必須嚴格按照年平均收入的相關基 數進行繳納,二類地區可以參考相關標準下浮5%,三類地區可以按照相關標準下浮 10%, 四類貧困縣區域的自由職業者可以根據自身實際情況進行自由繳費。靈活的設計就是為 了給貧困地區人員減輕繳費負擔。
    (3)繳費年齡。充分考慮男女人員身體特性及現有勞動法對男女職工對退休年齡的 規定(男職工60周歲,女職工55周歲退休),達到法定年齡的可按照低于5%的相關基數 參保;大于法定年齡不足30歲的,我們要求按照相關基數核定;大于30歲不足50歲的, 我們按照相關基數 10%進行核定;大于 50 歲的,我們按照相關基數的 10%進行核定。
    (4)繳費性別。一般男同志我們按照總基數的 0.5 倍進行核定,女同志按照總基數 的 0.3 進行核定, 未成年人員按照 0.2 進行核定。
    (5)繳費學歷。對所有的自由職業者,按照博士、碩士、本科、大中專高中及以下分 別選取不同參數進行核定。總的原則是“學歷越高、繳費核定越高”。比如博士學歷按照 5倍基數核定,碩士按照4倍基數核定,本科按照3倍基數核定,高中以下則為1倍基數 核定。
    (6)工作年限。對于之前有參加過工作的自由職業者,我們為其測定了三個年限檔 位,為別為 15年、10年、5年及以下,其中 15年及以上的按照繳費基數3倍核定, 15 年以下10年以上的按照2倍基數進行核定, 10年以下5年以上按照1倍基數核定。還有 其他相關分擔比例、分擔系數等,其中權重最大的是“年度收入”,它是我們繳費核定的 關鍵。
    第四章 系統詳細設計
    近些年,陜西省始終堅持“保基本、可持續、廣覆蓋”的方針,扎實落實《社會保險 法》相關要求和規定,在增強公平性、適應流動性、保證可持續性等方面不斷發力,逐步 實現了頂層制度的從無到有,從單點到多點,從局部到整體覆蓋,實現了信息系統的從無 到有,從“粗”到“精”,從單點登錄到全省通用,從試點推廣到全省覆蓋。可以說,信 息化保障能力和水平實現了巨大的提升。陜西職介代征信息管理系統緊緊結合自由職業 者工作靈活、參保靈活、繳費靈活的實際,結合銀行代繳網點和經辦機構網點多的實際進 行了詳細設計,實現了業務高效辦理。
    4.1系統的建模
    4.1.1靜態結構設計圖
    靜態結構圖,即描述系統的靜態部分。在定義系統類,表示各類之間關系的同時,也 包含其內部結構。在面向對象進行分析設計時,不同問題會有不同的解決方案,在考慮內 部和外部關系聯系的同時,充分考慮系統的各對象自身,及個對象之間關系,從而建立系 統的對象模型。根據系統的需求分析、總體架構設計,可知系統包含了復雜的功能模塊, 這些模塊總體聚合起來就實現了從個人管理、單位管理到參保登記繳費管理、系統管理等 各個功能,包含了種類繁多的類和接口,在描述系統總體結構時,我們嘗試使用系統的包 圖來表示。如圖 4-1 所示。
    1 1 1
    單位及用戶管理 報表管理 權限管理
     
     
    1 1 1
    查詢分析 系統管理 門戶管理
     
     
    1 1
    征繳管理 職介機構管理 數據管理
    圖 4-1 系統的包圖
    Figure 4-1 System Package Diagram
     
    關鍵的類有日志管理信息、基礎信息、繳費管理、信息查詢等。其中日志信息類圖 PersonGroupCommLogListAction 類與 CommLogGroupQueryCmd 類之間相互依賴。他們的 眾多屬性和方法或是操作均為Publico如圖4-2所示。
     
    圖 4-2 日志類圖
    Figure 4-2 Log Class Diagram
    個人基本信息對象涉及到眾多的類,比如有關查詢的PersonlnfoInternetQuerCmd類和 PersonInfoInternetSearchAction 類等,它們所有類的屬性也均為公開,基本的操作為 set 或 是geto如圖4-3所示。
     
     
     
    圖 4-3 個人基本信息類圖
    Figure 4-3 Personal Basic Information Class Diagram
    繳費核定類圖當中 CancetAgentContritionCreateCmd 類和 CollectDatailIinfoQueryCmd
    類是其中的核心類,它們的關系相對就復雜些。如圖4-4 所示。
     
     
    圖 4-4 繳費核定類圖
    Figure 4-4 Personal Basic Information Class Diagram
    信息查詢類圖中,幾乎所有類的操作最終都指向了 ACOlView,可見其所查詢的核心。
     
     
    圖 4-5 信息查詢類圖
    Figure 4-5 Information Service Class Diagram
    4.1.2對象關系設計圖 通過對系統應用進行深入分析和研究,我們得出了單位、用戶、報表、任務、權限等 為系統的主要對象,且清楚了各個對象之間的關系。比如上級用戶設計了任務且屬于單位, 而權限又控制單位,當任務發布給地市用戶時,地市用戶填表相關任務上報給上級用戶, 同時上級用戶又審批著地市填報的任務。同時填報的報表屬于任務且報表又有一些指標 屬于公示的范疇。相關的指標對象之間關系如圖4-6所示。
     
     
    圖 4-6 系統對象關系圖
    Figure 4-6 System Object Diagram
    4.1.3動態結構設計圖 系統登陸工作流圖清晰地反映了用戶登錄從開始權限認證,認證通過后,緊接著加載 系統功能菜單,等到功能菜單加載完結后,出現了條件判斷選擇,是基本信息還是繳費信 息,最后結束整個業務流程。當系統網站進行登陸時,若不成功則需要返回重新登陸,若 成功則進行用戶權限控制,加載系統功能菜單,繳費或者基本信息變更,若是繳費相關信 息,則分別進行個人繳費和批量繳費,隨后結束流程;若選擇基本信息,則分別個人業務 批量辦理和個人基本業務辦理,等到操作完結后,隨即結束流程。我們可以看到整個流程 非常清晰,條件判斷也非常簡單且易于操作。從這里我們可以得到啟示,清晰的工作流可 以幫助我們更好的理解系統經辦業務流程,明確業務經辦的條件,保障業務高效合理流轉。 系統工作流如圖4-7所示。
     
     
     
    圖 4-7 系統登陸工作流
    Figure 4-7 System Principal Workflow
    4.2系統模塊功能設計
    在系統模塊功能設計時,我們以單獨的命名形式,依據相關的需求,考慮各個模塊 的獨立性,為的就是保障系統整體功能的完整性。職介代征信息管理系統主要包含基本 信息管理、繳費核定、信息查詢、綜合管理等功能。基本信息模塊涵蓋了個人參保登 記、基本信息變更、參保信息復核、工作待遇變更、復核等。繳費核定模塊包含:個人 繳費核定、繳費核定作廢、銀行代繳核定、繳費核定作廢、核定匯總作廢、制定銀行代 征計劃等。信息查詢模塊包括:個人信息、單位信息及交接匯總、退休等信息等。其中 個人信息包含:個人基本信息、個人繳費信息、個人繳費工資、養老人員轉移信息、養 老個人繳費信息、個人賬戶信息、醫療個人賬戶信息等;單位信息包含:單位基本信 息、單位年度社保信息、單位遲退人員信息、單位繳費臺賬信息及花名冊;退休信息包 含:退休人員基本信息、退休人員繳費信息、退休人員賬戶信息等。整體的模塊功能設
     
    計如圖 4-8 所示。
     
    Figure 4-8 Function Design Diagram Of System Module
     
    4.2.1基礎信息
    職介信息管理系統的設計功能非常強大,尤其是基礎信息管理功能模塊。基本實現了 自由職業者和經辦機構及代征銀行的所有機構和人員管理。個人管理包括如下功能:個人 新參保登記、個人信息變更申報、個人停保申報、個人續保申報、年度工資申報、個人繳 費工資修改申報、分支機構內轉移、授權等。
    個人新參保登記功能可以使單位新參保、繳費單位新招職工或從未繳費單位調入職 工,或獨立繳費人員完成新增參保登記。個人信息變更申報功能可以使參保人員完成基本 信息的變更。個人停保申報可以使因入伍、入學、辭退除名、勞改勞教、中止合同等原因 與單位中斷工作關系的職工完成保費停繳。個人續保申報可以使參保人員停保后又有單 位錄用繼續參加社會保險時,恢復繳費。年度工資申報可以使單位按年申報完成個人年度 工資。
    下面以個人基本信息變更為例,詳細設計個人管理的個人基本信息變更功能,它可以 實現個人新參保登記、個人基本信息變更及個人基本信息復核,參保人員暫停、恢復繳費, 甚至包含個人年度基數申報等。基本功能清單如表4-1 所示:
    表 4-1 基礎信息功能清單表
    Table4-1 Basic Information Function List
    編號 功能名稱
    1 人員新參保登記
    2 人員基本信息變更
    3 人員基本信息復核
    4 參保人員暫停繳費
    5 參保人員恢復繳費
    6 個人基數變更
    7 年度基數申報
    職工因入伍、入學,或者被辭退或其他原因被除名,或是勞改勞教等原因與單位中 斷勞動工作關系,單位為其停止繳納保險費時,本人應該攜帶《參保人員增減變動表》、 入學(入伍)通知書或是其他相關證明和手續材料,到代理機構辦理停止參保手續,直 到系統錄入完畢,審核無誤后,停保狀態即可生效。
    針對參保人停止參加養老保險后又被原單位或是其他單位錄用繼續參保的情況,我 們也是慎重對待的。尤其當恢復某個人社會保險關系和個人參保資料,修改個人基本信 息(如所屬單位信息等)和參保信息時,我們都需要非常充分的證明材料,同時每個環 節的審核也是相當的仔細。比如,記錄的人員變更信息,錄入繳費基數,重新核定繳費 基數,確定繳費類型等情況發生時,我們都會嚴格審核。
    4.2.2繳費核定
    系統的繳費核定功能主要針對已繳費情況的查詢和核定。其對象主要為:參保個體 和繳費人員、靈活就業人員、自由職業者等,根據獨立繳費繳費狀態(即本期是否正常 參保和正常繳費)、繳費基數、繳費比例等按對應費款所屬期生成養老保險的指定期間應 繳明細信息和應繳總額。繳費核定信息我們可以清晰的看到有關個人和單位的繳費核定 信息,銀行代繳和回盤結算的相關信息,同時對繳費核定匯總信息和繳費核定匯總作廢 信息也可以操作。繳費功能清單如表4-2 所示。
     
    表 4.2 繳費核定功能清表
    Table4-2 Basic Information Function List
    編號 功能名稱
    1 個人繳費核定
    2 單位繳費核定
    3 繳費核定作廢
    4
    銀行代繳核定
     
    銀行回盤結算
    6單位預繳核定
    7繳費核定匯總
    8繳費核定匯總作廢
    繳費金額的核定,通過導出的DBF表,由銀行接收,代為收繳。代理機構在銀行繳納 核定費用后,將銀行回盤文件導入本系統,生成到賬數據。允許代理機構一次繳納養老保 險待等待劃轉基金的業務。等待劃轉基金的金額可以是任意的,可以是定額的,也可以是 根據一定規則計算出的。
    4.2.3信息查詢
    對個人基本信息,包含養老轉移、繳費及個人賬戶等信息;對單位信息,包含單位繳 費花名冊、單位基本信息、單位辭退人員、繳費臺賬等信息;同時對交接匯總、退休人員 基本信息、離休人員支付等信息均可實現查詢。信息查詢基本功能清單如表 4-3 所示。
    表 4.3 信息查詢基本功能清單表
    Table4-3 Information Query List
    編號 功能名稱
    1 個人基本信息查詢
    2 個人繳費工資信息
    3 養老人員轉移信息
    4 養老個人繳費信息
    5 養老個人賬戶信息
    6 單位繳費花名冊
    7 單位基本信息
    8 單位辭退人員信息
    9 單位繳費臺賬信息
    10 交接匯總信息查詢
    11 退休人員基本信息
    12 離退休人員支付信息
     
    4.2.4系統管理
    系統管理功能主要實現代理機構下屬分支機構信息的增加、刪除,對分支機構進行授
    權,相互轉移。系統管理基本功能清單如表4-4所示。
    表 4.4 系統管理基本功能清單表
    Table4-4 System Management List
    編號 功能名稱
    1 下屬分支機構管理
    2 分支機構用戶授權
    3 人員轉移分支機構
     
    4.3系統數據庫設計
    職介代征管理信息系統采用了 Oracle數據庫系統,也是目前最流行的B/S/S體系結 構的數據庫之一。Oracle數據庫系統有很多版本,目前最新版本為oracle 12c。而職介 代征信息管理系統采用的是Oracle 10g數據庫,因為在降低了管理開銷的同時極大的提 高了數據處理性能,同時還兼顧了成本和效率。
    4.3.1數據庫設計原則
    Oracle 10g有高可用性、同時還支持數據的回盤與刷新操作;改進和提升了了 SQL 各項服務能力,比如分析能力、最短路徑有限(OLA P)、數據挖掘能力等等;在對關系 型數據庫進行各項能力提升的同時,也對非關系型數據存儲能力進行了提升。在設計本 項目的數據時,我緊緊結合數據庫設計規律,主要遵守了很多數據庫設計的原則,此處 主要介紹系統表設計和字段設計所依據的原則[44]。
    就數據表的設計原則而言:一方面遵循了規范的化設計原則。規范化可以減少數據 冗余,減輕數據存儲壓力,從而節約了存儲空間,對應的邏輯和物理的輸入輸出次數也 就會大幅度減少,在減少操作的同時也大大加快了增、刪、改的速度和效率。但是規范 的設計并不一定是最優的設計,因為對數據查詢而言,它往往需要更多的連接操作,這 勢必就會影響查詢進度,從而影響整體效率。另一方面堅持對數據表分類進行說明的原 則[45]。多數情況下,數據表分類依據的是應用實際本身和需要本身,大體可分以下幾 類:一是基本數據表:描述業務實體的基本信息。例如,人員基本信息、單位基本信息 等。二是編碼標準表:主要對職稱、民族、狀態等狀態進行描述。三是業務數據表:主 要對人員調動登記、變更通知等業務發生的過程和結果進行記錄登記。四是系統信息 表:主要存放用戶信息、權限、用戶配置信息等系統操作、業務控制有關的參數。五是 統計數據表:主要存放通知單統計、人員類別統計等表[46]。
    就數據字段設計原則而言:通常情況下,正確的存儲,數據的最小類型是數據字段 設計必須要考慮的[47]。當我們不確定數據類型時,應當遵循選擇以不會超出范圍的最小 類型作為設計原則。其次,盡可能選擇簡單的數據類型。因為越簡單的數據類型占用的 空間小,比較的規則也更簡單。比如,比較整數就比比較字符用的時間少,占用的空間 也少。再次盡可能把字段定義為非空。對于字段能否為空,在數據庫建表腳本中應明
    確,最好不要使用為默認的缺省值。最重要的是單個表中的字段不超過90。
    4.3.2數據庫設計規范
    在本系統數據庫設計的過程中,首要把握兩個原則:一是數據庫中不存放無用的數 據表和字段;二是存儲過程統一使用中文的包名和過程名。在本系統數據庫設計中,我 重點做了以下幾方面努力。
    一是盡力避免表中為空的列。縱然設計表中允許空列的存在,空字段是一種特色的 數據類型,相應的它也有著特別的意義。二是盡可能避免重復的值。數據庫設計時盡量 避免重復值或者列的產生[48]。當遇到重復出現或者需要重復出現在多張表單中的字段 時,寧可設置多張表,將其另外設置一張表,也不要重復。也就是說,盡量將重復的值 放置到一張獨立的表中進行管理。視圖是聯系這些獨立的表的重要手段。三是標識符與 表中記錄對應。每一個條記錄均有一個ID來實現標記,不需要通過名字、編號等字段來 區分。四是設定統一的前綴名。在開發之初,就充分的調研,制定了一個規范的數據庫 對象前綴名。
    4.3.3數據一體化和分類設計 本系統涵蓋各級單位和人員信息,數據量大、數據類型也非常繁雜,同時數據表結 構也比較復雜,單張數據表也比較大,表之間的關系也非常的復雜。其數據關系圖如圖
    4-9 所示。
     
     
     
    單f立衰更惱息
    BAAUU4 VARCHAR2(32) <ok>
    AABUU] VARCHAR2 (16) 5k. £k>
    AAE140 VARUHAR2(3) <uk>
    AAE1DO VARCHAR2(3 )
    AAB101 VARCHAR2(10)
    匸#occ、
    圖 4-9 數據關系圖
    Figure 4-9 Relation Ship Of Database
     
    從數據應用的角度看,職介代征信息管理系統與其他系統和機構實現對外數據交 換、服務支撐均離不開交換數據庫,交換數據庫的存在即滿足了適時數據的查詢需要, 又避免查詢直接訪問核心庫造成核心庫數據的安全隱患。交換庫定期從核心庫拿取數 據,同時將自己的數據備份于核心庫。對于其他的外部應用來講,數據交換庫、服務支 撐庫、決策支持庫則分別發揮著各自的作用。具體應用分布策略如圖4-10所示。
     
    圖 4-10 應用分布策略圖
    Figure 4-lO Application Distribution Strategy Map
     
    4.3.4數據表設計
    本系統涉及到的數據表非常多,本文僅對部分數據表,比如數據庫基本信息表,單 位基本信息、單位參保信息、個人基本信息、個人參保信息、個人繳費信息等基本數據 表進行設計與描述。
    表 4-5 單位基本信息數據表 B_ABOl
    Table 4-5 Unit Basic Information Data Table B ABOl
    是否主鍵 字段名 字段描述 數據類型 長度 可空 備注
    AAB001 單位編號 VARCHAR2(15) 15 ★單位編號
    BAA001 數據分區編號 VARCHAR2(10) 10 數據分區編號
    BAB801 單位內碼 VARCHAR2(15) 15 單位內碼
    BAB802 單位助記碼 VARCHAR2(15) 15 單位助記碼
    BAB808 單位企業自編號 VARCHAR2(15) 15 單位企業自編號
    AAB002 社會保險登記證編碼 VARCHAR2(20) 20 社會保險登記證
    編碼
     
     
    表 4-6 單位參保信息數據表 B_AB02
    Table 4-6 Unit Participation Information Data Table B AB02
    是否主鍵 字段名 字段描述 數據類型 長度 可空 備注
    AAB001 單位編號 VARCHAR2(15) 15 ★單位編號
    AAE140 險種類型 VARCHAR2(3) 3 ★險種類型
    BAA001 數據分區編號 VARCHAR2(10) 10 數據分區編號
    BAB501 雙基數標志 VARCHAR2(3) 3 雙基數標志
    AAB050 參保日期 VARCHAR2(10) 10 參保日期
    AAB051 參保狀態 VARCHAR2(3) 3 參保狀態
     
     
    表 4-7 單位變更信息 B_AB04
    Table 4-7 Unit Participation Information Data Table B AB04
    是否主鍵 字段名 字段描述 數據類型 長度 可空 備注
    BAA004 交易流水號 VARCHAR2(32) 32 交易流水號
    AAB001 單位編號 VARCHAR2(15) 15 ★單位編號
    BAA002 變更原因 VARCHAR2(100) 100 變更原因
    BAA001 數據分區編號 VARCHAR2(10) 10 數據分區編號
    BAB801 單位內碼 VARCHAR2(15) 15 單位內碼
    BAB802 單位助記碼 VARCHAR2(15) 15 單位助記碼
     
     
    表 4-9 個人基本信息 B_AC01
    Table 4-9 Personal Basic Information B AC01
    是否主鍵 字段名 字段描述 數據類型 長度 可空 備注
    AAC001 個人編號 VARCHAR2(12) 12 ★個人編號
    BAA001 數據分區編號 VARCHAR2(10) 10 ★數據分區編號
    BAC808 個人企業編號 VARCHAR2(12) 12 個人企業自編號
    AAB001 單位編號 VARCHAR2(15) 15 單位編號
    AAC002 公民身份號碼 VARCHAR2(18) 18 公民身份號碼
    AAC005 民族 VARCHAR2(3) 3 民族
     
     
    表 4-10 個人參保信息表 B_AC02
    Table 4-10 Personal Insurance Information B AC02
    是否主鍵 字段名 字段描述 數據類型 長度 可空 備注
    AAC001 個人編號 VARCHAR2(12) 12 ★個人編號
    AAE140 險種類型 VARCHAR2(3) 3 險種類型
    BAA001 數據分區編號 VARCHAR2(10) 10 數據分區編號
    AAC030 個人參保日期 VARCHAR2(10) 10 個人參保日期
    AAC031 個人參保狀態 VARCHAR2(3) 3 個人參保狀態
    AAC008 人員狀態 VARCHAR2(3) 3 人員狀態
     
    表 4-11 人員轉移信息表 B_AC06
    Table 4-11 Personal Transfer Information B AC06
    是否主鍵 字段名 字段描述 數據類型 長度 可空 備注
    AAE062 人員轉移流水號 VARCHAR2(32) 32 ★人員轉移流水號
    AAE076 財務接口流水號 VARCHAR2(32) 32 財務接口流水號
    AAE140 險種類型 VARCHAR2(3) 3 險種類型
    AAC001 個人編號 VARCHAR2(12) 12 個人編號
    AAC003 姓名 VARCHAR2(20) 20 姓名
    AAC002 公民身份號碼 VARCHAR2(18) 18 公民身份號碼
     
    4.3.5數據庫性能設計 在保持數據完整性的前提下,盡可能減少數據冗余。這是傳統數據庫范式規范化理 論的本質,即“把雞蛋盡量放在一個籃子”,為的就是不必要、非必要的異常插入、異常 刪除以及異常更新等。可以說,數據庫設計本質目的就是為了實現“用盡可能多的空 間,換更快的時間”。
    具體從硬件和軟件兩個方面進行設計和部署。 硬件方面:一是采取“雙機”原則。自動分攤數據讀取壓力,實現負載均衡,始終 保障有一臺數據服務器安全平穩運行。二是采取光纖線路。為了更好提升數據庫與應用 服務器之間的讀取速度,使其達到GB級的數據傳輸速率,我們對關鍵線路采用光纖線 路。
    軟件方面:合理配置內存存儲,加大內存存儲容量。在相同硬件配置下,給數據處 理留出大空間,盡可能加快數據讀取、存儲速度,提升業務辦理效率。
    算法方面:為設備和應用系統提供優良的算法,充分考慮了算法的時間復雜度,實 現高效處理。比如采取最小連接數、哈希算法、搜索均衡樹等。
     
     
    第五章 系統實現與測試
    職業介紹代征信息管理系統所有功能均采納快捷的O/RMapping映射機制。采用了優 良的面向對象開發方法,采用了基于J2EE的B/S/S三層體系架構,實現了系統預設的各項 模塊功能。 B/S/S 三層體系架構的靈活運用,為系統按照時間節點順利完成開發奠定了 基礎作用,B/S/S三層體系架構的靈活運用,在確保系統本身具有高度的易用性和穩定 性的同時,也為后期的各項功能擴展提供了技術保障和支撐。
    5.1系統總體實現 依據對陜西省城鎮職工養老保險業務的研究分析,結合職介中心和自由職業者的需 求,對業務指標體系進行了合理化升級和拓展,實現了依托軟件配置解決業務需求問題, 既實現了快速開發,又實現了高度復用。系統目前包括基礎信息、繳費核定、信息查 詢、系統管理等功能,實現了全省職介機構和靈活就業人員的登記、繳費、查詢、系統 管理等業務經辦,實現了經辦全過程的信息化、網絡化,支持與相關單位(企業、銀 行、地稅等)的信息交換,促進養老保險經辦機構實時掌握職介中心的基金征繳,規避 職介代征機構“滯押”社會保險基金的情況。
    5.2系統各功能模塊實現
    通過測試,我們實現了基礎信息、繳費核定、信息查詢、系統管理等模塊預設的各 項功能,也滿足了職介代征機構的各項功能需求。由于系統依托金保工程業務專網運 行,故以內網測試環境為主進行介紹。在地址欄輸入:http://10.189.128. 227:9005/ 進入陜西省社會保險職業介紹代征信息管理系統登陸主界面。登陸首頁如圖5-1所示。
    ④ 映西aua保險■理信恵議統?樓心平臺三牘
    Sh?anXI Province Social Insurance Management Information Systems Core Platform Version 3
     
    圖 5-1 系統登陸界面
    Figure 5-1 System Login Interface
     
    5.2.1基礎信息管理實現 基礎信息管理包括個人新參保登記、人員基本信息變更、人員參保信息復核、參保 人員暫停繳費、參保人員恢復繳費、個人基數變更、年度基數申報等功能。以個人新參 保登記為例,如圖5-2 所示。
     
     
    5.2.3信息查詢實現 信息查詢包含個人基本信息查詢、個人繳費工資查詢、養老人員轉移查詢、養老個 人繳費信息查詢、養老個人賬戶信息、單位繳費花名冊、單位基本信息、單位申報信息 查詢、單位遲退人員基本信息、單位繳費臺賬信息、交接匯總信息、退休人員基本信 息、退休人員支付信息、退休人員賬戶信息等。以交接繳費匯總為例,如圖 5-4 所示。
     
     
     
     
     
     
    KiW: i,WWitet no”:佔姐,
    圖 5-4 交接繳費匯總
    Figure5-4 Summary Of Transfer Payment
    5.2.4系統管理實現
    系統管理模塊包括下屬分支機構管理、分支機構用戶授權、人員轉移分支機構。以
    分支機構用戶授權為例,如圖 5-5 所示
     
    5.3系統配置及軟件
    測試環境的基本要求就是首要保證穩定,在穩定的同時保證可控。應該盡可能的減 少測試花費時間,用最短時間完成測試用例的執行。尤其是針對額外的測試,我們要實 現的就是可以保證每一個被提交的缺陷都可以在任何時候被準確的重現。為此,我們嚴 格選定了服務器軟件項、測試機軟件項、測試工具等方面進行了調試。
    5.3.1服務器軟件項
    在采購系統的數據庫服務和Web應用服務時,我們嚴格按照系統需求設計,在滿足 系統最大負載正常使用的前提下,盡可能的提升處理能力。在降低總體項目成本投入, 保證項目所需硬件質量的前提下,盡可能利用舊設備。如表5-1 所示。
    表 5-1 服務器軟件項列表
    Table5-1 Server Software Item List
    資源用途 名稱/類型
    數據庫服務 Oracle 10G
    Web 應用服務 Weblogic 8.1
     
    5.3.2測試機軟件項
    對測試機的配置及測試軟件也做了要求。如表5-2所示。
    表 5-2 測試用機軟件項列表
    Table5-2 Testing Machine Software List
    標識 名稱/類型
    PC01 Windows XP Sp2 Internet Explore 8.0 JDK 1.4. 2
    PC02 Windows XP Sp2 Internet Explore 8.0 JDK 1.4. 2
     
    5.3.3測試工具
    測試工具我們根據不同的測試階段選擇不同的測試工具。如表5-3 所示。
    表 5-3 測試工具列表
    Table5-3 Testing Tool List
    資源用途 名稱/類型
    功能迭代測試 Rational Test Studio 2003.06.00 (IBM)
    測試過程數據及管理 Quality Center 9.0 (HP)
     
    5.3.4測試設備軟件設置
    測試時主要使用PC機,其操作系統為Windows XP SP3,瀏覽器為微軟MS Internet Explorer 8.0。測試過程中 MS Internet Explorer 8.0 的 Internet 選項設置為每次訪
    問時檢查。測試用機的顯示器分辨率為1024X768, 1280X800,保證各種界面條件下的 良好顯示。
    5.4硬件及固件項
    5.4.1網絡環境
     
     
     
    Figure 5-6 System Net Topology Schematic Diagram
    5.4.2硬件資源 在開發過程中,為了降低總體開發成本,我們始終堅持利舊原則。從主機服務器到
    應用服務器,再到數據庫服務器,我們還充分考慮了負載均衡及測試用機,組織專業第
    三方機構對系統進行了嚴格測試,經過測試各項數據指標均符合預定設計。具體的硬件 配置如下表5-4 所示。
    表 5-4 測試固件資源列表
    Table5-4 Test Firmware Resources List
    名稱 配置 型號 用途
    IBM 494 CPU:16CPU 內存:32 GB IBM 494 數據庫服務器
    HP8440 CPU:4CPU 內存:8 GB HP8440 應用服務器
    array CPU: Pentium4 內存:1GB TMS 2000 負載均衡
    PC01 CPU: Intel( R) core 2 2.13GHZ 內存: 1GB 硬盤: 160GB HP DC7700 測試用機
    PC02 CPU: Intel( R) core 2 2.13GHZ 內存: 1GB 硬盤: 160GB Dell Optiplex 774 測試用機
    5.5 測試說明
    測試前, 我們進行了充分的檢查和調試, 明確了測試的要求, 對標需求進行測試。
    測試過程中, 我們分兩個階段進行:第一階段 :采用等價類劃分法 、邊界值分析法等黑
    盒測試方法對系統進行全面測試,驗證系統功能的正確性及業務流程的處理是否符合用 戶的需求和滿足需求分析報告的規定。對于測試發現的問題,及時提交到QC上,開發方 及時進行修改。第二階段:待開發方將所有缺陷修復之后,將再次驗證系統已修復缺陷 的功能點的正確性,并對其業務相關聯的功能點也進行正確性驗證。若系統中功能處理 正確,業務邏輯均符合用戶需求及需求分析報告,測試完成。若未滿足,及時修改、調 整各項參數,重新調試,直到各項參數指標合格。
    5.5.1個人管理功能 個人管理功能中,我們對個人新參保登記功能進行了測試。詳見下表
    表 5-5 個人新參保登記測試列表
    Table5-5 Test Registration of new personal insurance List
    編號 用例描述 輸入數據 期望結果 實際結果 測試結果
    1 正常輸入 點擊“人員參保登記” 系統進入人員參 與期望一致 實現
    保登記查詢界面
     
     
    輸入單位編號,公民身份證 號號碼,單位編號: 系統進入人員參
    2 正常輸入 1010100001571,公民身份證
    號: 612323880512123)點擊 保登記主界面。 與期望一致 實現
    查詢按鈕。 系統給出提示,
    3 異常輸入 姓名為空,參加工作日期為 空,點擊“確定”按鈕。 提示:姓名、參 加工作日期不能 為空。 與期望一致 實現
    輸入姓名、參加工作日期、
    4 正常輸入 地址、郵政編碼、戶口所在 地、聯系電話、申報工資等 信息(如,姓名:梁子,參加 工作日期: 2008-03-01),點 擊“確定”按鈕。
    輸入已存在單位編號,公民 可成功添加該條 個人新參保登記 信息。 與期望一致 實現
    身份證號號碼,(單位編號: 系統可成功查詢
    5 正常輸入 1010100001571,公民身份證 出該參保人員的 與期望一致 實現
    號: 612323880512123)點擊 基本信息。
    “查詢”按鈕。
     
    5.5.2單位管理功能 單位管理功能中,我們尤其對繳費核定功能進行了測試。測試結果如表 5-6所示。
    表 5-6 繳費核定測試表
    Table5-6 Test Payment verification List
    編號 用例描述 輸入數據 期望結果 實際結果 測試結果
    1 正常輸入 點擊“繳費核定作
    廢”菜單
    所有信息為空,點擊
    “查詢”按鈕 系統顯示岀代理機構繳費 核定作廢查詢主界面。 系統給岀提示信息,提 與期望一致 實現
     
    2 異常輸入 示:主體編號和征集通知 流水號必修輸入一項。 與期望一致 實現
    3 正常輸入 輸入主體類型、主體 編號、征集通知流水 號、對應費款所屬期 系統可查詢岀該主體單位 與期望一致 實現
    等查詢條件(主體編 下的征集通知流水信息。
    號: 10100001571), 點擊“查詢”按鈕。
    選擇一個代理機構繳 系統可成功進行該文單位
    4 正常輸入 費信息,點擊“確 的繳費核定,并給岀操作 與期望一致 實現
    定”按鈕。 成功提示信息。
     
     
    5.5.3繳費核定功能 繳費核定中功能中,我們特別對銀行代繳核定功能進行了測試。測試結果如表 5-7
    所示。
    表 5-7 銀行代繳核定測試表
    Table5-7 Test Bank payment verification List
    編號 用例描述 輸入數據 期望結果 實際結果 測試結果
    1 正常輸入 點擊“銀行代繳核定”菜
    單。 系統顯示岀銀行繳費核
    定查詢主界面。 與期望一致 實現
    2 異常輸入 所有信息為空,點擊“查 詢”按鈕。 系統給岀提示信息,提 示:單位編號是必輸 項,請重新輸入。 與期望一致 實現
    輸入單位編號、繳費基 數、開始費款所屬期、截 止費款所屬期等查詢條件
    3 正常輸入 (單位編號:
    10100001571,繳費基 數:社平工資,開始費款 所屬期:200901,截止費 款所屬期:200912),點擊
    “查詢”按鈕。 系統查詢岀該單位下的
    銀行代繳核定信息。 與期望一致 實現
    4 正常輸入 點擊導岀“dbf”文件。 可成功導岀該文件。 與期望一致 實現
     
    5.5.4系統管理功能
    系統管理中,我們對下屬分支機構管理功能進行了測試,測試結果如表5-8所示。
    表 5-8 測試固件資源列表
    Table5-8 Test Firmware Resources List
    編號 用例描述 輸入數據 期望結果 實際結果 測試結果
    系統進入分支機構用戶
    1 正常輸入 點擊“分支機構用戶授 授權主界面,并以列表的 與期望一致 實現
    權”菜單。 形式顯示岀當前的用戶
    信息。
     
    2 正常輸入 點擊“授權”。 系統進入用戶基本信息
    授權主界面。 與期望一致 實現
    3 正常輸入 從可增加的分支機構 選擇一條記錄,點擊 “確定”按鈕。
    在用戶信息查詢輸入 系統可成功對該用戶進 行分支機構授權。 與期望一致 實現
    4 正常輸入 框中輸入查詢信息(用 戶編號:00000092),點 擊“查詢”按鈕。 可成功查詢岀該用戶信
    息。 與期望一致 實現
     
     
    5.6測試結果
    5.6.1功能測試結果
    本次測試過程中主要采用等價類劃分法、邊界值分析法、場景模擬法等黑盒測試方 法驗證系統各個功能點在日常業務處理中的查詢、分析、統計等功能的正確性及完整 性。對系統中各功能之間的關聯性進行了主要測試,尤其對系統數據的輸入和輸岀進行 了重點測試。以下是對被測功能點的正確性結論,其中所展現的結果是經多次測試修改 驗證后的最終結果。功能測試結果如表 5-9所示。
    表 5-9 各功能模塊測試結果
    Table5-9 Functional Modules List
    序號 測試功能點 測試要求
    1 綜合管理 個人業務日志 功能性
    個人新參保登記 功能性
    個人基本信息變更 功能性
    人員參保信息復核 功能性
    2 基礎信息 參保人員暫停繳費 功能性
    參保人員恢復繳費 功能性
    個人基數變更 功能性
    年度基數申報 功能性
    個人繳費核定 功能性
    單位繳費核定 功能性
    繳費核定作廢 功能性
    銀行代繳核定 功能性
    3 繳費核定 銀行回盤結算 功能性
    單位預繳 功能性
    繳費核定匯總 功能性
    核定匯總作廢 功能性
    個人基本信息 功能性
    個人繳費工資信息 功能性
    養老人員轉移信息 功能性
    4 信息查詢 養老個人繳費信息 功能性
    養老個人賬戶信息 功能性
    單位繳費花名冊 功能性
    單位基本信息 功能性
    單位年度申報信息 功能性
    單位遲退人員信息 功能性
    單位繳費臺賬信息 功能性
    交接繳費匯總 功能性
    退休人員基本信息 功能性
    退休人員支付信息 功能性
    退休人員賬戶信息 功能性
    下屬分支機構管理 功能性
    5 系統管理 分支機構用戶授權 功能性
    人員轉移分支機構 功能性
    5.6.2 易用性測試結果
    系統界面顏色搭配合理協調,頁面布局劃分簡潔明了,滿足了用戶日常業務辦理的 流程和使用要求,另外功能點的名稱遵循了需求分析報告中相關名稱,做到了用詞準 確、易懂,各個功能點的名稱命名中沒有模棱兩可的字詞,其次系統對運行過程中岀現 問題或引起錯誤的地方都有相關提示,能讓用戶明白錯誤岀處及原因,對提示、警告、 或錯誤的處理清楚、明了。
    5.6.3可維護測試結果 系統對資源的管理、數據字典、參數管理以及角色授權的管理和系統各項基礎參數 的定義,操作簡單易行,業務用戶經過培訓都能完全掌握對系統基礎數據的維護。對于 系統的應用發布和數據庫安全的維護性,測試過程中按照系統規劃中《BEA應用配置要 求》、《數據庫安裝說明》等系統維護文檔說明,系統在發布應用部署、對數據庫的恢 復、備份以及數據庫數據的導入和導出時用戶都可方便的進行,特別是對Web服務器的 發布維護包括停止、重起、配置,用戶都可以按照相關配置說明自行對系統進行維護。
    5.7評價
    5.7.1能力 測試結果表明,“職業介紹代征系統”需要完成的功能包括綜合管理、基礎信息、繳 費核定、信息查詢、系統管理等功能,且各項功能均已按要求全部實現。
    5.7.2缺陷和限制 在前期的測試過程中,發現的缺陷分布于系統的部分模塊中。其中以一些一般錯誤 和次要錯誤為主,亦存在一些重要錯誤。例如常見功能缺陷(添加、修改、刪除、查詢 功能失效,數據顯示岀錯,頁面鏈接失敗)和業務處理岀錯現象等;其次,在前期階 段,系統的提示信息不夠明確,界面風格并不是完全保持一致;系統的易用性和易操作 性也較差;伴隨著開發和測試的進一步并行深入和延續,所發現缺陷嚴重程度和數量都 呈下降趨勢。截至系統試運行期間及上線投入使用之后,其缺陷都已經全部解決。
    5.7.3建議 為了提高本系統的易用性及穩定性,建議在后續版本升級或開發的過程中,對系統 中的業務處理提示信息進行了優化,使得業務處理更加準確、明了,同時加強對界面布 局的合理優化,改進用戶對輸入信息的輔助支持,以使系統發揮更好的作用。
    5.8測試活動總結 本次測試活動中涉及的人員包括北京長天科技集團開發人員、陜西社會保障局各級 經辦用戶使用人員、部分代征代繳銀行工作人員,以及西安 863軟件孵化器有限公司的 測試人員。測試活動取得了預期的效果。
    第六章 總結與展望
    本文所介紹的職介代征信息管理系統的建設策略與方法,是在陜西省城鎮職工養老保 險信息系統的建設過程中積累起來的經驗與方法,目前,該系統運行平穩,解決了自由職 業者繳費,方便了征繳機構征繳,實現了對社保基金的監管,防止征繳基金“滯留”情 況的發生,保證了基金安全。
    6.1本文研究總結
    本文緊密結合自己工作實際,依托當前陜西省城鎮職工養老保險信息系統平臺建設 項目,通過對陜西省現有的城鎮職工養老保險信息管理系統現狀進行仔細和深入地學習 研究,基于軟件工程相關理論知識設計并實現了陜西省職業介紹代征信息管理系統。論 文主要工作成果如下:
    (1) 新開發的職業代征社會保險信息管理系統已經按照研究課題的要求,深化了我 省社會保險工作,提高了靈活就業人員參保的社會化、智能化服務水平,基本做到了“以 人為本、記錄一生、服務一生、管理一生、保障一生”。同時,實現了職業介紹代征機構 基金統一征繳,規避了職業介紹代征機構“滯押”社會保險基金情況的發生。
    (2) 在充分學習理解國家人力資源和社會保障部與陜西省省委省政府相關政策的基 礎上,基于系統工程思路和方法,本文調研、分析了陜西省職介代征業務需求并優化了 業務流程,完成了系統需求分析和概要設計。
    (3) 基于系統工程方法完成了職業代征社會保險信息系統詳細設計。本文分析設計 體系架構時,依托現有城鎮職工養老保險平臺,采用J2EE技術和MVC設計模式構建系統 軟件技術框架,采用Java編程語言解決了與客戶界面交互和數據處理,采用XML數據傳 輸方法,實現Client與Server的通信。同時,在數據庫設計時采用先進的ORACLE數據 倉儲技術,實現前端數據展現和后臺數據存儲與備份。
    (4) 在項目開發實施過程中,本人參與項目全部研究、設計和部分軟件開發工作, 無論是從前期的需求分析、架構設計、詳細設計,還是到后期的調試測試環境搭建都積 極參與,在學習提高的同時也提出了自己的意見和建議。
    (5) 系統已經在全省各級經辦機構上線運行,且當初設計的各項功能均能實現,尤 其是防止了基金的“滯留”,保證了基金的安全。系統自上線以來,運行平穩,滿足了全 省110 多萬自由職業者參保登記、繳費、待遇領取,滿足100 多個經辦機構保費征繳, 信息核對,提升了整體服務水平,也得到了各類使用群體的一致好評。同時也滿足業務 擴展的要求,為下一步全省“互聯網+政務服務”對接提供了平臺基礎。
    6.2未來工作展望
    在互聯網日益走進人民群眾生活的時代大背景下,我省現有的公共服務模式和平臺 已經遠遠不能滿足廣大人民群眾的需求,人民群眾渴望更加便捷、舒心的服務。社會保 險應用系統面對的是廣大的參保人員,管理的是參保人員的待遇享受,關系人民群眾的切 身利益,決不允許岀半點差錯,無論多小的失誤都會帶來巨大的影響,甚至影響全社會 的安定團結。隨著我國逐步進入人口老齡化時期,社會保險基金支付壓力會越來越大, 客觀上需要更加嚴格的管理發放機制,需要我們把每一分錢都用在刀刃上。只有我們時 時刻刻把普通群眾放在心上,時刻以他們滿不滿意、答不答應作為衡量工作的標準,我 們的工作才會越做越好。
    這些年,人社部門先后提岀了“人社信息化”、“信息化人社”、“互聯網+人社” 等先進理念,并在不同階段分別進行了實踐,這些理念的提岀和實踐均是基于對客觀現 實的正確判斷,特別是奮力推進社會保障卡一卡通,全面推進信息系統省級集中建設部 署,實現全省人社業務數據歸集,有效實現并推動了信息共享和業務協同。客觀來看, 群眾對人社信息化工作的全新需求,倒逼著社會保險政策制定更加合理完善,使得社保 業務經辦更加便捷高效。因此,應繼續對社會保險業務信息化經辦進行研究分析,實現更 高效、更便捷、更人性的社會保險服務模式。為此,今后應重點從以下幾方面著手:
    (1) 由于開發經驗欠缺,需求分析階段工作對接不充分,使得在一些細節方面存在 瑕疵,不夠完善,再加之時間緊急,部分功能模塊還有待進一步完善。比如查詢模塊 中,對查詢人員信息顯示不夠全面等,這些都是下一步需要優化、解決的問題。
    (2) 緊密結合“互聯網+人社 2020”專項行動計劃,積極探索公共服務平臺、
    12333 電話服務和短信服務系統延伸服務等,不斷拓寬系統應用的廣度和深度。
    致謝
    在攻讀碩士學位的過程中,西安理工大學的各位老師以其精湛的專業知識、循循善誘 的教學,在學業上給予我很多啟迪。特別是我的導師孫欽東教授, 他以其淵博的知識、嚴 謹的治學態度、豐富的閱歷,先后幫助我修改論文10 余次。論文從整體架構到細微格式 調整,他都一一指岀并督促修改。衷心感謝孫教授的悉心、耐心和熱心,有了他的幫 助,我的論文才能順利提交盲審,我才能順利答辯并畢業。在此謹向孫欽東教授以及西 安理工大學的其他各位老師致以誠摯的感謝和深深的敬意!
    本文是在我的學內導師孫欽東教授、校外導師陜西科技大學教授龔尚福教授的悉心 指導下完成的。文中所涉及的所有實踐素材和工程經驗,主要是在參加陜西省職業介紹代 征信息系統建設過程中取得的,在項目建設過程中,得到了當時項目辦的各位同事,特別是 陜西省人力資源和社會保障廳信息中心張建忠主任等同志的啟發、支持和幫助,使我在工 作中不斷進步,并得以組織本文的各種素材,使本文能夠順利完成。在此向他們也表示衷 心感謝!
    參考文獻
    [1] 鄧大松.社會保險.武漢大學出版社.2011,78-80.
    [2] 姜司堃.社會保險行政救濟存在的問題及對策研究.[湘潭大學碩士學位論文].湖南:湘潭大 學,2016,45-47.
    [3] 奕偉華.完善我國農村社會養老保險立法研究.[中國海洋大學碩士學位論文].山東:中國海洋大 學,2008,3-5.
    [4] 蘇海玲.中國農村社會養老保險模式研究.[山東大學碩士學位論文].山東:山東大學,2008,9-13.
    [5] 羅碧英.社會保障信息化建設的現狀分析與思考[J].廣東科技,2012 (7).
    [6] 呂勁松.社會保險信息管理系統中社保基金征繳管理的設計與實.[湖南大學碩士學位論文].湖南: 湖南大學,2010,04-10.
    [7] 陳海燕.云南省社會保險基金報表管理信息平臺的設計與實現.[山東大學碩士論文].山東:山東大 學,2014,35-42.
    [8] 劉恒禹.淺析當前社會保障信息化建設思路[M].電腦知識與技術.2016, 10-20.
    [9] 李致.陜西省社會保障水平的實證分析.[西北大學碩士學位論文].陜西:西北大學,2013,4-11.
    [10] 馮珍貞.加強社會保障信息化建設[J].中國新通信.2013 (6).
    [11] 翟新豐.社會保險信息系統建設探析[J].經營管理者.2011年05期.
    [12] 趙浩華.歐洲福利國家制度變遷研究.[黑龍江大學碩士學位論文].黑龍江:黑龍江大學,2018,70- 85.
    [13] 王華.社會保險管理信息系統中方法庫的設計與實現.[湖南大學碩士學位論文].湖南:湖南大 學,2010,20-30.
    [14] 楊文俊.美德日社會保險制度比較研究.[吉林大學博士學位論文].吉林:吉林大學,2007,5-8.
    [15] 唐鈞. 中國的社會保障政策評析. 東岳論叢.2008, (01):12-35.
    [16] 李冰倩.社保信息化應走好可持續發展之路.中國社會保障.2010,(11).
    [17] 陳欣.公共職業介紹機構促進青年就業研究--以上海靜安區為例.[華東政法大學碩士論文].上 海:華東政法大學,2015,48-59.
    [18] 程相天.社會保險管理系統的研究與實現.[同濟大學碩士學位論文].上海:同濟大學,2008,5-15.
    [19] 徐超.從信息孤島到信息共享--社會保險信息化建設路徑探討.[江西財經大學碩士論文].江西: 江西財經大學,2015,48-59.
    [20] 黃曉敏.陜西省城鄉基本養老保險統籌探析.[西北大學碩士學位論文].陜西:西北大學,2011.
    [21] 林萬潔.人力資源和社會保障系統中職業介紹子系統的設計與實現.[吉林大學碩士論文].吉林: 吉林大學,2011,48-59.
    [22] 韓瑤.基于工作流的人力資源管理系統的設計與實現.[內蒙古碩士學位論文].內蒙古:內蒙古大
    學,2016,18-27.
    [23]田鵬.社會保險管理信息系統的設計與開發.[湖南大學碩士學位論文].湖南:湖南大學,2007,11- 29.
    [24]胡曉明.基于可重用架構的社會保險管理系統的設計與實現.[同濟大學碩士學位論文].上海:上 海同濟大學,2007,3-10.
    [25] 張曉亮.基于J2EE電商平臺的設計與實現.[吉林大學碩士論文].吉林:吉林大學,2018,10-15.
    [26] 田柯.J2EE持久層的解決方案[J].計算機工程,2003.
    [27] 林道寧.基于 Spring+Struts2 的游船移動售票系統的設計與實現.[廈門大學碩士論文].福建:廈門大 學,2017,10-15.
    [28] 王少峰. 面向對象技術 UML 教程. 北京:清華大學出版社,2006,08.
    [29] 劉純.基于MVC設計模式的Struts技術在B/S系統中的研究與應用[D].西安建筑科技大學.2007.
    [30] 王碩.基于Spring+Struts2的游船移動售票系統的設計與實現.[大連交通大學碩士論文].大連: 大連交通大學,2018,10-15.
    [31] 張昕.基于B/S/S架構的醫療保險管理系統開發與實現.[吉林大學碩士論文].吉林:吉林大 學,2018,35-65.
    [32] 劉楠.銀行賬務管理系統的設計與實現.[天津大學碩士論文].天津:天津大學,2014,38-60.
    [33] 邱哲等.Struts Web設計與開發大全[M].清華大學岀版社,2006:12.
    [34] 宋曉曉.基于Ajax與MVC模式的短信業務綜合管理系統.[安徽工業大學碩士論文].安徽:安徽工 業大學,2018,10-15.
    [35] 王亮亮,郭慶平,廖小青.基于Struts的銀行績效考核系統的設計與實現[J].微計算機信 息,2008(12):24-25+44.
    [36] Marty Hall,Servlet與JSP權威指南[M],北京:機械工業岀版社,2002.
    [37] [美]Nadir Gulzar著,陳曉燕,丁炎炎譯.實用J2EE應用程序體系結構[M].北京:北京清華大學 岀版社,2003:67-68.
    [38] 趙強.基于開源軟件的J2EE企業級應用開發[M].電子工業岀版社,2005:56.
    [39] Joeeph J.Bambara, Paul R.Alen, J2EE 技術內幕[M].北京:機械工業岀版社,2002.
    [40] (美)約克姆(Yochem A. ) . J2EE 與 BEA Weblogic Server[M].電子工業岀版社,2006.
    [41] 任中方,張華等.MVC模式研究的綜述[J].計算機應用研究,2004:29 (10) 1-4.
    [42] 張湧.基于J2EE技術的電子政務網站系統設計與應用.[長春工業大學碩士論文].吉林:長春工業 大學,2018,10-15.
    [43] 洪維恩,何嘉.Java2面向對象程序設計[M].北京中國鐵道岀版社.2005.
    [44] 孟津平.Oracle數據庫下的系統性能調整與優化的研究.[長春理工大學碩士論文].吉林:長春理 工大學,2018,33-45.
    [45] Sheth A P Larson J A.Federated Database Systems for Managing Distributed,Heterogeneous nd Autonomous Database. ACM Computing Surveys.1990,223(3):183-236.
    [46]普里斯著,馮銳,由淵霞譯.Oracle Database 10g SQL開發指南.清華大學岀版社,2005.5.
    [47](美)鮑威爾著,沈潔譯.數據庫設計入門經典.北京:清華大學出版社,2007.10.
    [48]Zhao Ping,Labor and Social Security Department to develop mature 20 billion yuan proguamme can be
    launched narionwide agricultural security.”21st Century Economic Report”.February 24,2005,5-10.
    【本文地址:http://www.bzhlmm.com//guanlilei/gongshangguanli/xixinguanli/8876.html

    上一篇:上海聯通機房運維信息管理系統 設計與實現

    下一篇:沒有了

    相關標簽: