1、說明 1. 本文僅作為工程碩士論文格式排版范文使用，論文內容不做為優秀論文使用。如有和軟件工程碩士論文規范沖突的地方以規范為準。2. 本頁非論文正式內容，正式內容從下頁開始。分類號：TP311 單位代碼：10422密 級： 學 號：200412671碩士學位論文論文題目: 電信業務數據稽核管理系統的設計與實現作者姓名 周波 專 業 軟件工程 導 師 合作導師 2012年10月10日原創性聲明和關于論文使用授權的說明原創性聲明本人鄭重聲明：所呈交的學位論文，是本人在導師的指導下，獨立進行研究所取得的成果。除文中已經注明引用的內容外，本論文不包含任何其他個人或集體已經發表或撰寫過的科研成果。對本文

2、的研究作出重要貢獻的個人和集體，均已在文中以明確方式標明。本聲明的法律責任由本人承擔。論文作者簽名： 日期： 關于學位論文使用授權的聲明本人完全了解山東大學有關保留、使用學位論文的規定，同意學校保留或向國家有關部門或機構送交論文的復印件和電子版，允許論文被查閱和借閱；本人授權山東大學可以將本學位論文的全部或部分內容編入有關數據庫進行檢索，可以采用影印、縮印或其他復制手段保存論文和匯編本學位論文。（保密論文在解密后應遵守此規定）論文作者簽名： 導師簽名: 日期： 目 錄目 錄ICONTENTSIII摘 要VABSTRACTVII第1章 緒論81.1 系統開發背景81.2 國內外研究現狀91.3

3、解決的主要問題91.4 本文的主要工作101.5 論文的組織結構10第2章 電信業務數據稽核管理系統需求分析122.1 總體業務描述122.2 系統目標和解決的問題142.3 系統需求問題描述152.3.1系統功能性需求152.3.2系統非功能性需求27第3章 系統設計293.1系統技術架構303.2 系統功能架構313.2.1 系統功能組成31第4章 系統詳細設計334.1 系統建模334.1.1 系統的整體模型結構334.2 詳細設計分析344.2.1 掃描模塊詳細設計344.2.2定單稽核的詳細設計374.2.3專項稽核的詳細設計384.3系統接口設計404.4系統數據庫設計43第5章

4、系統實現與測試475.1開發環境：475.2系統實現：47第6章 結論與展望77參考文獻79致 謝81CONTENTSChinese AbstractiEnglish AbstractiiiChapter 1 Introduction71.1 Development background for the audit system of telcom business71.2 The latest state of technology81.3 The main problems need to be resolved in this paper81.4 The main work of thi

5、s paper91.5 The structure of this paper9Chapter 2 The requirement analysis of the audit system of telcom business112.1 Introduction to the audit system of telcom business112.2 Project goal of the audit system of telcom business122.3 The discription of requirement for the audit system of telcom busin

6、ess132.3.1 Functional requirement132.3.2 Non- functional requirement25Chapter 3 Construction design for the audit system of telcom business263.1 Desing aim and principle for this system263.2 Technology construction design273.2.1 Technology construction for the audit system of telcom business27Chapte

7、r 4 Detail design for the audit system of telcom business294.1 System modeling for the audit system of telcom business294.1.1 Model structure of this system294.1.2 The whole structure of this system364.2 Model design of this system304.2.1 The detail design for the otherness management304.2.2 The det

8、ail design for the integrative management33Chapter 5 Implement and test for the audit system of telcom business435.1 The whole implement for the audit system of telcom business42Chapter 6 Conclusion43Referrences44Acknowledgements45摘 要電信重組后市場競爭日趨激烈，各個運營商為提升市場競爭力，推出大量捆綁業務和組合產品，資費下調、利潤空間減少，運營商在控制成本的同時，

9、更加注重保障收入的完整，同時業務復雜度顯著增加，由于系統限制不足和人為因素，經常會出現業務違規辦理的情況，導致各種錯收漏收。另一方面，由于業務數據涉及多個平臺，各平臺之間存在頻繁數據交互，因系統問題等因素會導致平臺間出現數據的不一致的情況，影響用戶服務和收入準確性。由于電信業競爭激烈，導致運營商紛紛下調資費，利潤空間減少；因此各運營商在控制成本的同時更加注重收入確保。加強內控管理，確保業務受理的規范性和合理性，保障收入完整，成為運營商一項非常重要的工作。電信業務數據稽核管理系統是近年興起的運營商對企業業務數據進行稽核管理的有效工具。它通過系統對各平臺間的數據一致性和業務合規性進行校驗，并對異常

10、數據進行閉環派單整改，確保業務數據的準確性、完整性和一致性，實現了業務稽核工作的電子化、流程化、自動化管理，大大降低了稽核工作的人工成本和復雜程度，提高了相關工作效率，確保了稽核工作的全面性和準確性，為收入保障和內控工作提供了強有力的支撐，從而有效避免收入流失和各類服務問題，并以此為手段來提高企業的獲利能力、收入以及客戶滿意度。本文通過分析電信業務數據稽核管理的實際需求和業務流程，設計和實現了一個針電信行業的業務數據稽核管理系統。首先，本文在討論電信業務數據稽核管理系統項目背景和對其開發設計所面對問題的基礎上，分析了系統的功能需求和非功能性需求，并對系統需求以流程圖和用例圖的形式來詳細說明。在

11、需求分析基礎上，我們進行了電信業務數據稽核管理系統架構設計。首先根據系統需求提出系統設計目標和原則，然后分別對系統技術架構和功能架構進行了設計。技術架構主要考慮系統的可擴展性，可維護性以及性能問題。再一步進行電信業務數據稽核管理系統的詳細設計。該部分對各個模塊的設計進行了描述。第四部分在詳細設計的基礎上，首先對各個模塊的實現進行了簡單介紹，給出了系統的整體效果圖和各個部分的實現。最后，本文對電信業務數據稽核管理系統的應用情況作了簡單介紹，并對系統進一步改進提出了建議。綜上所述，我們在分析業務需求和客戶關系管理思想的基礎上，設計并實現了電信業務數據稽核管理系統。關鍵字：電信行業，業務數據稽核，軟

12、件工程 ABSTRACT Keyword: Telecommunications，Telecom Business Data Auditing，Software engineering82 第1章 緒論1.1 系統開發背景當前電信行業營業規模、收入總量迅速擴大，光纖寬帶、3G、移動增值等業務快速增長，各個運營商開始向綜合信息服務提供商轉型，提供的產品及業務種類顯著增加。另一方面，電信重組后市場競爭日趨激烈，各個運營商為提升市場競爭力，推出大量捆綁業務和組合產品，業務復雜度顯著增加，因系統限制不足和人為因素，也會出現業務違規辦理的情況，導致各種錯收、漏收。另一方面，由于業務數據涉及多個平臺，各平

13、臺之間存在頻繁數據交互，因各種因素會導致數據的不一致的情況，影響用戶服務和收入準確性。另一方面，電信行業競爭導致運營商紛紛下調資費，利潤空間減少；因此各運營商在控制成本的同時更加注重保障收入完整。加強內控管理，確保業務受理的規范性和合理性，保障收入完整，成為運營商一項非常重要的工作。目前，運營商的業務數據稽核工作大都采用人工方式，通過人工檢查來對各個業務環節的數據進行比對，查找漏洞進行補收。這種方式因人力有限，只能停留在受理資料完整性、用戶是否欠費等淺層次的稽核工作上；無法做到深入分析各種業務規則漏洞，及時、全面、準確的稽核出各種違規業務數據。另外稽核出的異常數據全靠人工來調度整改，整改結果靠

14、人工匯總上報，工作量極大且無法實現閉環管理，造成異常數據不能及時得到整改，不能夠真正達到避免收入流失的效果。面對人工稽核的不完善帶來的日益嚴重的收入流失的現狀，亟需建設業務數據稽核系統，來自動實現對各類業務數據的一致性、合規性進行稽核，并對數據整改調度進行自動化、流程化、閉環管理。從而提高稽核的工作效率和稽核的全面性、準確性，加強收入保障，防范內控風險。1.2 國內外研究現狀根據IDC、普華永道、RHK等國際知名咨詢公司發表的報告，在全球50多家電信運營商中，約有三分之一的公司因計費或欺詐行為而蒙受重大損失，損失約占其年度總收入的5%15%。收入流失既嚴重影響企業經營業績，又制約了企業的正常發

15、展，因此各個運營商都已經開始高度重視收入保障工作，陸續開始建設業務數據稽核平臺。目前國內已有平臺主要實現了對異常業務數據的分析和提取，但是缺少對后續整改工作的流程管控，也未實現與業務流程的密切結合。同時電信業務具有復雜多變的特點，很多平臺存在擴展性和靈活性不足的缺點，對后續新增業務的支持能力不夠。1.3 解決的主要問題電信業務數據稽核管理系統是建立在整個電信業務系統基礎上上的子系統，該系統通過生產系統獲得業務數據，并根據事先配置好的稽核規則，對數據進行校驗，生成存在異常的業務數據，并通過閉環的派單流程發送到責任部門進行整改，直至數據修正準確。系統必須具備以下特點：1、 系統必須實現對紙質定單的

16、電子化，改變以往因稽核紙質定單，紙質定單傳遞耗時時間過長帶來的稽核延時，提高稽核效率。2、 系統能夠根據預先定義的規則進行自動化稽核。3、 針對電信業務復雜多變的特點，系統設計必須通用性強，具備高度擴展性。4、 系統必須與稽核業務流程高度結合，實現從異常數據生成、派單、整改、復核在內的全閉環管理，實現對電信業務稽核工作的全面支撐。5、 稽核內容全面，既包括對業務定單合規性的稽核，又包括計費收入數據稽核和平臺間數據一致性稽核，覆蓋收入保障的所有范圍。6、 稽核過程需要對海量業務數據進行處理，處理能力必須高效，能夠滿足各類業務時限要求。如何設計滿足以上需要的電信業務稽核管理系統是本文要解決的主要問

17、題。1.4 本文的主要工作本文分析了電信業務數據稽核管理系統的實際需求和業務流程，并結合收入保障和數據稽核理論，設計和實現了電信業務數據稽核管理系統。首先，本文討論了電信業務數據稽核管理系統項目背景和所面對問題，介紹了國內國際的系統現狀。在此基礎上分析了系統的稽核業務流程，進而分析系統的功能需求和非功能性需求，將系統需求以流程圖和用例圖的形式詳細說明。在需求分析基礎上，討論電信業務稽核管理系統架構設計。首先根據系統需求提出系統設計的目標和原則，然后將架構設計分為系統技術架構和功能架構分別進行討論。技術架構要求考慮系統的可擴展性，可維護性以及性能問題。在技術架構討論中，首先分析了系統的網絡架構和

18、系統數據存儲結構，然后在邏輯架構討論中，分析了J2EE架構分層模型，并對各層的功能進行了分析。在功能架構分析中，討論了系統各部分的功能組成，最后給出一個動態的系統功能流程。其次，進行電信業務數據稽核管理系統的詳細設計。根據需求分析來設計系統，并對各個模塊的設計進行了描述。在系統建模中，為了更加充分的理解系統的設計，我們簡單介紹了電信業務系統總體架構，并分析了業務數據稽核管理系統在其中的作用和位置。然后給出了電信業務數據稽核管理系統的整體結構圖。在了解了整體結構之后，介紹了各個模塊的詳細設計。在詳細設計中，利用狀態圖和交互圖進行設計分，給出了詳細設計類圖。再次，我們在詳細設計的基礎上，對各個模塊

19、的實現進行了介紹，給出了系統的效果圖。在詳細分析的最后，分析了系統測試，并對壓力測試的環境搭建和測試過程進行了詳細討論。最后，本文對電信業務數據稽核管理系統的應用情況作了簡單介紹，并對系統的設計和實現進行了總結，提出了對系統的展望和改進建議。1.5 論文的組織結構第1章緒論，主要描述系統的開發背景、業務數據稽核管理的國內外現狀，本文解決的主要問題和完成的工作。第2章系統需求分析，主要進行系統的需求分析。首先進行了電信業務數據稽核管理系統的概述。其次描述了該系統的系統目標和解決的問題。最后對需求分析按照功能需求和非功能需求兩個類別進行描述。第3章系統架構設計，主要進行系統的架構設計。首先對系統的

20、設計目標和原則進行了闡述。其次，在技術架構設計中，分別按照物理架構和邏輯架構進行設計。最后詳細描述了系統功能架構的設計過程。第4章系統詳細設計，本章主要進行系統的詳細設計。首先在系統建模部分，在對電信業務系統整體模型結構描述的基礎上，對電信業務數據稽核系統的整體結構進行設計。其次進行了各個模塊的詳細設計。第5章系統實現與測試，首先描述了系統的整體實現，并對各個模塊的實現進行了描述。其次本章描述了系統測試的情況，并對壓力測試進行了詳細描述。第6章對論文進行了總結，并對系統的進一步提升提出了改進意見。第2章 電信業務數據稽核管理系統需求分析2.1 總體業務描述電信業務數據稽核是收入保障管理的主要工

21、作，內容涉及從業務受理、服務開通、計費賬務全業務流程，需要各級業務、職能管理部門全面參與。電信業務數據稽核管理系統包括業務定單稽核子系統、平臺數據稽核子系統、專項稽核子系統、整改派單子系統;每個子系統又包含多個功能模塊。各個子系統的主要業務描述如下：一、 檔案掃描子系統實現用戶證件和定單的掃描上傳，掃描件用于對用戶簽字和證件進行稽核以及實現紙質檔案的電子化；在處理客戶與受理相關的投訴時，可以在線（內部辦公網絡）實時通過定單號、證件號快速查詢定單和證件的掃描件。二、 業務定單稽核二級稽核人員對證件、定單掃描件以及所有定單業務辦理的合規性進行稽核，對存在問題的定單派單到相應營業廳進行整改；營業員整

22、改完畢后，二級稽核人員對整改結果進行復核，市公司市場銷售部的三級稽核人員則對全市定單稽核和整改情況進行抽查，對發現存在問題的定單派單到二級稽核進行處理整改，二級稽核根據實際具體差錯進行相應的整改處理或繼續派單到營業廳進行整改。業務定單稽核子系統實現了對上述稽核過程的電子化、實時化、系統流程化管理，主要包括定單多條件組合篩選及導出、定單稽核（批量稽核、循環稽核）、差錯整改、整改復核、三級稽核模塊、吉祥號管理（動態配置吉祥號規則進行吉祥號定單稽核提取）。三、 平臺數據稽核子系統平臺數據稽核子系統主要包括自動核對模塊（固話核對模塊、寬帶核對模塊、移網核對模塊）、數據關聯集中展現模塊、數據定時自動同步

23、模塊。1、對固話、寬帶、2G、3G在業務系統中的數據和相應平臺間的數據進行一致性比對，核對內容包括號碼是否存在、功能服務是否一致、費用賬期是否合規等；提取差異安排相關責任進行部門整改。2、以受理定單號作為入口提取各平臺相關數據，進行集中展現，解決了人工查詢需要各系統切換的繁瑣。3、定時自動同步部分核心數據，提高基礎信息一致性（如為保證登陸工號、部門一致性：每天定時同步員工表、部門表、產品表、動作表等）。四、 專項稽核子系統根據收入保障的相關要求，針對特定可能存在的業務漏洞，制定相應稽核規則，檢查出存在問題的用戶數據，并組織專項整改。五、 派單整改子系統各稽核子模塊生成的差異數據通過派單整改子系

24、統派單到職能部門進行審核，審核通過后發送責任部門進行整改，整改完畢后對結果進行復核，復核通過后流程結束，實現業務數據稽核整改的全閉環管理。六、 統計查詢主要提供檔案掃描統計查詢、定單稽核統計查詢、專項稽核統計、差錯受理統計、稽核超時統計、差錯整改統計等功能。七、 系統管理主要實現對稽核參數進行配置；分配用戶權限；稽核人員稽核范圍配置等；包括：公告管理、日志管理、專項稽核接口管理、自動稽核接口管理、角色管理、密碼管理等。關于上述七個子系統的詳細功能框架，將在系統需求分析一章中給予詳細說明。2.2 系統目標和解決的問題系統設計和實現達到以下目標：1 實現對客戶定單、證件的掃描上傳，對受理定單、客戶

25、簽字、證件的電子化查詢和稽核，避免紙質定單人工傳遞帶來的稽核延時及查詢的不便性。2 實現對業務定單的自動化稽核，對業務受理的合規性進行自動檢查，對不需人工復核的定單自動通過或退回，減去人工稽核工作量，實現定單稽核的全面性，避免因抽查造成的漏檢情況。3 實現對用戶數據的自動化稽核，對業務系統數據與交換網元數據進行一致性和完整性檢查，對不一致或缺失的部分進行報錯并提醒，稽核人員可以只對報錯部分進行針對性的稽核，提高稽核效率。4 系統提供工單處理流程，對異常數據根據業務需要分解和流轉到相關部門處理。通過工單在各環節間流轉來完成數據整改工作跨部門的配合和連接。5 系統實現對稽核規則和工單流程的配置化管

26、理，可根據實際業務邏輯的變化通過配置接口界面調整實際的稽核規則和工單處理流程，實現調整的快速化、簡單化。6 系統應提供全面的統計分析和考核功能，系統必須在每次稽核后，對數據采集、數據稽核、工單處理、數據整改等提供相應的日、周、月統計報表。所有統計報表，均需要提供表格和圖表方式進行綜合呈現。對所有稽核結果形成按照市、區縣、鄉鎮營業部維度和業務維度的統計報表，以便對相關部門的差錯和整改情況及進行考核。2.3 系統需求問題描述2.3.1系統功能性需求1. 系統涉及的崗位需求 業務數據稽核系統涉及的崗位如圖2-3所示：圖 2-3 業務數據稽核系統崗位如上圖所示，每個崗位對應著不同的操作職責和權限，分別

27、如下：(1) 營業人員對應的職責有：定單掃描、證件掃描、受理差錯整改。用例圖如下：(2) 二級稽核人員對應的崗位職責有：定單二級稽核、受理差錯整改情況復核、專項稽核差錯整改。用例圖如下：(3) 三級稽核人員對應的崗位職責有：定單三級稽核、專項稽核派單、專項稽核整改復核。用例圖如下：(4) 系統管理員職責有：工號管理、權限管理、稽核點配置。(5) 專項稽核配置人員職責：專項稽核規則配置、專項稽核任務執行。(6) 平臺維護人員職責：負責平臺異常數據的核查整改工作。2.業務流程及用例在分析了系統的崗位設置之后，本文分業務檔案掃描、業務定單稽核、平臺一致性稽核、專項稽核、派單整改、統計分析、系統管理六

28、部分來整理系統需求。(1) 檔案掃描子系統檔案掃描子系統包括證件掃描、定單掃描、協議掃描三個功能模塊，證件及定單掃描的處理流程如下圖所示： 用戶到前臺進行業務辦理，營業員首先對證件進行掃描上傳，然后為用戶在系統中辦理相關業務，打印受理定單，用戶簽字后，收取相關費用，業務辦理完畢，然后對定單進行掃描。 證件掃描模塊菜單名稱證件預掃描適用角色范圍 營業員 二級稽核 稽核班長 三級稽核 專項稽核調度 專項稽核處理 稽核邏輯開發 系統管理員 公共查詢目的當受理單未進入稽核系統，或者遇到業務較多來不及逐筆掃描定單，或者客戶需要著急走不能等待的情況下，可以預先掃描并保存客戶證件（也需要考慮方案支持拍照，目

29、前高拍儀正在測試中）功能要求1. 能夠初始化掃描儀2. 掃描的證件可以記入登錄者本人名下（默認），也可以記入本營業廳其他營業員名下（可以下拉框選擇）3. 掃描件最多可以上傳6份4. 掃描時選擇掃描件的類型，包括：身份證（單張）、身份證（用戶/經辦人）、駕照、護照、戶口簿、a4（其它）5. 掃描后的證件保存在服務器上并記錄該證件屬于哪個工號其他要求證件掃描上傳后系統需要在證件的圖片上加上水印（chinaunicom 掃描件的時間），以確保掃描件符合市公司要求，即證件只能在同一天、同一營業員、同一客戶使用，二級稽核可以在稽核環節看到水印人工判斷定單掃描模塊模塊名稱定單掃描適用角色范圍 營業員 二級

30、稽核 稽核班長 三級稽核 專項稽核調度 專項稽核處理 稽核邏輯開發 系統管理員 公共查詢目的對于從生產系統進入了稽核系統的工單，進行定單及證件等紙質憑證的掃描。功能要求1. 本菜單打開后能夠默認顯示本登錄工號下的所有未掃描的工單，顯示的信息包括：流水號、服務號碼、業務類型，并顯示以下憑證是否掃描：客戶證件、業務定單、 其他證件（包含經辦人、擔保人、付費人的證件）、費用減免依據（包括協議、營銷方案申請、簽字減免等紙質憑證）、其他2. 也可以按照流水號，單個查詢3. 可以初始化掃描儀4. 可以打開某個定單，然后掃描該定單的客戶證件、業務定單、 其他證件（包含經辦人、擔保人、付費人的證件）、費用減免

31、依據（包括協議、營銷方案申請、簽字減免等紙質憑證）、其他5. 除業務單外的其他證件信息，可以現掃描也可以從自己已經預掃描過的證件里面選擇6. 業務定單能夠支持掃描、復印、拍照7. 如果是關聯業務的話，不用重復掃描，掃描完一筆定單（作為主單）后其他定單可以直接通過輸入主單流水號而共享掃描件。輸入主單流水號的時候需要有以下限制條件：1） 主單流水號不能與當前流水號相同2） 主單流水號必須已經提交給二級稽核了3） 主單流水號必須與當前流水號的業務是同一受理人、同一天、同一業務類型、同一網別8. 可以輸入備注9. 可以輸入營銷方案申請、合同會簽的協議或者簽字流程的OA編號10. 支持暫存、保存提交，保

32、存提交是指的該定單掃描件已經全了可以提交給二級稽核11. 打開定單除了能夠掃描外，還能夠顯示該定單的定單操作歷史日志，包括：順序、處理人、動作、處理時間、所屬部門、處理意見（結果）其他要求1. 無法掃描情況的處理：針對部分代理商或營業點沒有掃描儀或者掃描儀故障超過3天以上不能掃描上傳的情況， 在營業員掃描業務單的地方可以選擇“掃描”或“復印”。默認是掃描，即默認是需要掃描上傳業務單的，但是如果部分代理商或營業點沒有掃描儀或者掃描儀故障超過3天以上不能掃描上傳的情況，可以選擇復印，營業員辦理業務時復印用戶證件，粘貼在定單后面。在營業員掃描定單的操作界面，點擊復印選項（一般默認為掃描定單），此類定

33、單系統允許在無關聯定單、無任何掃描件的情況下上傳提交至二級稽核。但是如果沒有選擇復印，則在保存提交的時候系統需要驗證：“必須掃描客戶證件！或與其他定單相關聯”2. 合并打印的關聯提交對于像沃家庭這樣一筆 多筆流水的情況，融合系統允許多張業務單合并打印到一張上去，這樣掃描上傳只需要在沃家庭主單上掃描上傳一份即可，其他流水的單子就不需要掃描上傳。因此，需要加一個功能：如果是標志為合并打印的，允許有一筆主單掃描上傳后提交，其他同一定單號下面的其他所有流水號批量關聯上傳。3.定單關聯模塊菜單名稱批量定單關聯適用角色范圍 營業員 二級稽核 稽核班長 三級稽核 專項稽核調度 專項稽核處理 稽核邏輯開發 系

34、統管理員 公共查詢目的對同一工號受理的掃描件可以共享，或者只需要一個主單提供掃描件其他被關聯單不需要提供掃描件的情況，對這種定單進行批量的關聯功能要求1. 輸入或選擇一個主關聯定單號，需要有如下限制條件：主關聯定單只能是已經掃描并提交的定單，在主單可供選擇的界面中也應該顯示的是已經掃描并提交的定單2. 選擇被關聯定單，需要有如下限制條件：1） 被關聯單必須是未提交的定單2） 主關聯單與被關聯單必須是同一受理人、受理時間在同一天、同一業務類型、同一網別3. 關聯后的所有單子就統一批量提交給二級稽核了。4. 按時間段可以該營業員名下選擇沒有提交過的定單5. 通過復選框選擇可以關聯的定單進行關聯，支

35、持全選、重置6. 單次關聯定單數<=100筆其他要求批量定單關聯的需要系統加上批量定單關聯的標志，需要能區分出哪個是主單、哪些是與這個主單關聯的被關聯單（2）定單稽核子系統 稽核規則配置能夠根據業務變動靈活配置新稽核規則，稽核業務邏輯與系統界面分離，實現松耦合管理，提高系統可擴展性。自動稽核每天晚上業務系統的數據會被同步到省公司統一提供的查詢數據庫，業務稽核管理系統將所需數據從查詢數據庫中抽取本地，然后根據事先配置好的稽核規則執行自動稽核任務，生成異常數據，異常數據包括差錯類別，差錯描述等信息。輔助稽核可根據稽核人員指定的條件，提取需要稽核定單的與稽核相關的關鍵信息，如客戶信息、用戶信息

36、、賬務信息等。相關信息可導出EXCEL表，用于輔助稽核。稽核完畢后可填寫稽核結果，選擇差錯種類并對差錯進行描述。菜單名稱等待稽核定單適用角色范圍 營業員 二級稽核 稽核班長 三級稽核 專項稽核調度 專項稽核處理 稽核邏輯開發 系統管理員 公共查詢目的二級稽核對營業員提交上來的、且竣工后的定單進行稽核功能需求1. 可以通過查詢條件查詢出該二級稽核人員管轄的稽核范圍內的所有未稽核的定單2. 可以點擊打開查看單筆定單詳情3. 系統自動稽核的結果顯示在定單詳情里面4. 可以導出查詢出來的定單的信息，導出時需要哪些字段可以手工選擇5. 可以單筆稽核通過或退回（包括通過、通過并繼續、退回、退回并繼續、跳過

37、暫緩稽核）6. 可以多筆定單通過退回，界面功能包括：全選、取消全選、當頁批量通過、當頁批量退回、全部批量通過、關聯批量通過（主單通過，與主單關聯的單子也一并通過）、關聯批量退回（主單退回，與主單關聯的單子也一并退回）7. 增加一個查詢條件“是否批量關聯”，如果選擇“是”可以查詢出所有批量關聯定單的主單的信息， 點擊主單后彈出定單詳情界面時，定單詳情界面上增加一個可以查看所有被關聯單信息的地方。如果點擊查看被關聯單，則可以看到被關聯定單的列表，再點擊某個定單，可以進入看到該定單的定單詳情查詢條件定單號、流水號、網別、業務類型、品牌、產品(套餐)、自檢狀態、三級部門、受理部門、受理人、時間范圍（指

38、的是受理時間）、是否上傳（含有以下項目：全部（默認的）、已上傳、未上傳）、受理系統（含有以下項目：E側、B側）、是否批量關聯（是、否）/*有關聯標志的*/、定單形式（全部定單、掃描定單、紙質定單 /*指的是無掃描儀或掃描儀損壞的情況下紙質報送的部分*/）、 查詢結果在界面上展示的信息定單號（按定單號排序）、流水號、服務號碼、關聯號、業務類型、產品、客戶名、受理人、受理部門、自檢（自檢通過、自檢差錯、輔助稽核通過、輔助稽核差錯），以下信息顯示是否掃描即可：客戶證件、業務定單、 其他證件（包含經辦人、擔保人、付費人的證件）、費用減免依據（包括協議、營銷方案申請、簽字減免等紙質憑證）、其他導出和每個

39、定單的詳細信息需要的字段定單號（按訂單號排序）、流水號、業務號碼、業務類型、賬戶標識、網別、品牌、新產品名稱、原產品名稱、受理點、受理人、受理工號、新客戶名稱、原客戶名稱、證件號碼、證件類型、證件地址、原裝機地址、裝機地址、聯系、聯系電話、用戶類型、用戶性質、營業費用、預存款、押金、付費方式、原速率、新速率、新增優惠、取消優惠、新增服務、取消服務、用戶關系變化（新增）、用戶關系變化（取消）、sp信息（新增和取消）、付費關系信息（新增和取消）、帳務優惠信息（新增和取消）、欠費金額、實時結余、備注、吉祥號碼類型、自檢差錯信息、是否上傳、協議編號、 單筆定單需要顯示的定單詳情流水號、業務號碼、受理人

40、、受理點、產品、業務類型；以下掃描件：業務定單、客戶證件、其他證件（包含經辦人、擔保人、付費人的證件）、費用減免依據（包括協議、營銷方案申請、簽字減免等紙質憑證）、其他；掃描件可以放大查看，也可以打印。關聯定單號、自檢信息、掃描提交備注、二級稽核退回原因（輸入文本框）、差錯類型（可選擇，可配置）；定單操作歷史日志：順序、處理人、動作、處理時間、所屬部門、處理意見（或結果）其他要求差錯處理營業人員可查看差錯定單，并對差錯進行整改，整改完畢后填寫整改結果。菜單名稱定單稽核差錯處理適用角色范圍 營業員 二級稽核 稽核班長 三級稽核 專項稽核調度 專項稽核處理 稽核邏輯開發 系統管理員 公共查詢目的營

41、業員對二級稽核人員稽核出差錯被退回的定單進行整改處理功能需求1. 顯示本工號被退回的所有定單信息：流水號、服務號碼、業務類型、產品、客戶名、自檢（自檢通過、自檢差錯、輔助稽核通過、輔助稽核差錯），以下信息顯示是否掃描即可：客戶證件、業務定單、 其他證件（包含經辦人、擔保人、付費人的證件）、費用減免依據（包括協議、營銷方案申請、簽字減免等紙質憑證）、其他2. 可以手工刷新、定時刷新3. 可以按照流水號單筆查詢4. 可以點擊打開查看單筆定單詳情5. 對某筆定單進行證件、定單等憑證的重新上傳，也可以記錄差錯整改的情況單筆定單需要顯示的定單詳情流水號、業務號碼、受理人、受理點、產品、業務類型；以下掃描

42、件：業務定單、客戶證件、其他證件（包含經辦人、擔保人、付費人的證件）、費用減免依據（包括協議、營銷方案申請、簽字減免等紙質憑證）、其他；關聯定單號、自檢信息、掃描提交備注、稽核退回原因、差錯類型（可選擇、可配置）；定單操作歷史日志：順序、處理人、動作、處理時間、所屬部門、處理意見（或結果）其他要求掃描件可以放大查看，也可以打印整改復核二級稽核人員查看整改結果，對營業員整改情況進行復核，對存在問題的進行退單繼續整改，對整改完畢的復核通過。模塊名稱整改復核適用角色范圍 營業員 二級稽核 稽核班長 三級稽核 專項稽核調度 專項稽核處理 稽核邏輯開發 系統管理員 公共查詢目的二級稽核退回的差錯定單營業

43、員整改后再次提交的定單，二級稽核進行復核功能需求1. 界面上默認顯示本月營業員整改后再次提交所有定單2. 可以通過流水號查詢單筆定單，也可以通過時間范圍等信息查詢多筆定單3. 可以點擊打開查看單筆定單詳情4. 對于二次提交的單筆定單可以填寫二級稽核退回原因，可以對這筆定單進行通過（包含通過并繼續）、退回（包含退回并繼續）、跳過暫緩稽核處理5. 也可以對多筆進行通過或退回處理，包括：全選、取消全選、當頁批量通過、當頁批量退回、全部批量通過、關聯批量通過（主單通過，與主單關聯的單子也一并通過）、關聯批量退回（主單退回，與主單關聯的單子也一并退回）查詢條件流水號、網別、業務類型、品牌、產品、受理部門

44、、時間范圍查詢結果在界面上展示的信息定單號（按定單號排序）、流水號、服務號碼、關聯號、業務類型、產品、客戶名、受理人、受理部門、自檢（自檢通過、自檢差錯、輔助稽核通過、輔助稽核差錯），以下信息顯示是否掃描即可：客戶證件、業務定單、 其他證件（包含經辦人、擔保人、付費人的證件）、費用減免依據（包括協議、營銷方案申請、簽字減免等紙質憑證）、其他單筆定單需要顯示的定單詳情流水號、業務號碼、受理人、受理點、產品、業務類型；以下掃描件：業務定單、客戶證件、其他證件（包含經辦人、擔保人、付費人的證件）、費用減免依據（包括協議、營銷方案申請、簽字減免等紙質憑證）、其他；掃描件可以放大查看，也可以打印。關聯定

45、單號、自檢信息、掃描提交備注、二級稽核退回原因（輸入文本框）、差錯類型（可選擇，可配置）；定單操作歷史日志：順序、處理人、動作、處理時間、所屬部門、處理意見（或結果）其他要求（3）平臺數據稽核子系統 主要實現對固話業務、小靈通業務、寬帶業務、GSM業務的客戶資料數據與相應平臺數據進行比對；生成差異結果，并通派單子系統完成下發、整改、反饋等。平臺數據稽核子系統分為以下兩個模塊： 計劃任務定制管理模塊系統應支持計劃性的任務管理，能夠對采集、稽核、工單等進行任務定制。計劃任務定制應能靈活選擇需要稽核的數據源業務系統、數據源業務屬性以及稽核規則等項目，且各項目可以靈活組合形成一個完整的計劃任務。計劃任

46、務管理應支持多任務的并行執行機制，使多任務能夠并行執行，提高系統的運行效率。系統支持年、月工作計劃的制定與審核，工作計劃是任務的集合，系統應該能夠按月、按年等粒度，統計工作計劃完成的全面性和及時性。數據采集和校驗模塊稽核數據范圍包括以下平臺和系統：1固話交換機平臺：2寬帶業務平臺（亞信平臺等）3智能網平臺4HLR（西門子、華為、貝爾等）5OCS系統數據采集應該具備以下功能：1數據采集應能根據采集請求，向業務支撐系統或網元提取原始數據，并進行數據的完整性校驗。2系統應提供對采集任務進行配置的功能，包括采集周期、采集啟動時間以及采集任務對應的腳本等。3系統應能對采集情況進行跟蹤，可查詢歷史采集任務

47、的原始交互日志，了解采集任務執行情況。4必須支持對數據的過濾、清洗、比對的功能，能夠根據實際數據情況對數據進行多重的數據處理。數據校驗應具備以下功能：1數據稽核行為必須是可自定義的，能夠通過界面的配置化進行業務的擴充。2數據的稽核應該支持上百萬級別的數據量的比對工作。數據稽核應支持多任務并發。數據稽核應在2小時內完成。3系統應能提供生成差異性報告的功能，并提供差異結果導出功能。4稽核結果展現應包括各相關平臺的具體差異信息，以及比對數據的所有相關屬性。2.3.2系統非功能性需求1. 可靠性(1) 排除人為誤操作因素，由應用系統自身原因導致的系統崩潰故障,平均無故障時間（MTBF）應大于90天，平

48、均修復時間（MTTR）應小于4 小時。(2) 應用系統必須支持連續7×24 小時不間斷地工作，應用軟件中的任一構件更新、加載時，在不更新與上下構件的接口的前提下，不影響業務運轉和服務。(3) 系統必須采用增量備份和全備份相結合的方式定期備份重要的系統數據。2. 易使用性(1) 應用系統必須提供一致性的圖形用戶界面風格。(2) 應用系統對普通用戶的操作界面應該以B/S 方式實現。(3) 應用系統必須支持同時打開多個管理窗口以對不同任務進行并行的操作。3. 可維護性(1) 系統在運行過程中所發生的任何錯誤都應該有明確的錯誤編號，并能在系統的相應維護手冊中查到錯誤處理方法與步驟。(2) 應

49、用系統應該采用構件化設計思想，系統框架與業務邏輯分離；要求具備開放的體系結構。(3) 應用系統應該支持通過統一的圖形界面能夠訪問到系統各構件、合約的版本信息及相應功能說明。(4) 應用系統必須支持各構件的單獨升級，并應該盡可能實現在線升級功能。4. 可移植性(1) 應用系統應該不需改動或盡可能少的改動就可以在不同的主流UNIX（IBM、HP、SUN）及Linux 平臺下方便的移植。(2) 應用系統必須支持客戶端軟件版本的自動升級。第3章 系統設計 系統設計是把用戶需求轉化為軟件系統的最重要的技術開發環節，系統設計的好壞從根本上決定了軟件系統的優劣，系統軟件設計的核心內容包含以下5個方面：體系結

50、構設計、用戶界面設計、數據庫設計、模塊設計、數據結構設計和算法設計，幫助開發人員搞清楚“設計什么”和“如何設計”，系統設計過程劃分為兩個階段：高層設計階段和詳細設計階段。高層設計階段的重點是體系結構設計，詳細設計階段的重點是用戶界面設計、數據庫設計、模塊設計、數據結構設計和算法設計等。3.1 系統技術架構系統的體系機構應該滿足“合適性、結構穩定性、可擴展性、可復用性”1、合適性，即體系結構應適應“功能性需求”和“非功能性需求。2、結構穩定性，體系結構一旦設計完成，應當在一定的時間內保持穩定不變，只有這樣才能使后續工作順利開展。3、可擴展性，是指軟件擴展新功能的容易程度，可擴展的前提條件是“保持

51、結構穩定”4、可復用性，應分析應用域的共性問題，然后設計出通用的體系架構模式，這樣的體系機構才可被復用。為滿足以上要求，本系統采用SSH架構，SSH 為 struts+spring+hibernate的一個集成框架，是目前較流行的一種Web應用程序開源框架。 集成SSH框架的系統從職責上分為四層：表示層、業務邏輯層、數據持久層和域模塊層，以幫助開發人員在短期內搭建結構清晰、可復用性好、維護方便的Web應用程序。其中使用Struts作為系統的整體基礎架構，負責MVC的分離，在Struts框架的模型部分，利用Hibernate框架對持久層提供支持，業務層用Spring支持。具體做法是：用面向對象的

52、分析方法根據需求提出一些模型，將這些模型實現為基本的Java對象，然后編寫基本的DAO(Data Access Objects)接口，并給出Hibernate的DAO實現，采用Hibernate架構實現的DAO類來實現Java類與數據庫之間的轉換和訪問，最后由Spring完成業務邏輯。 系統的基本業務流程是： 在表示層中，首先通過JSP頁面實現交互界面，負責傳送請求(Request)和接收響應(Response)，然后Struts根據配置文件(struts-config.xml)將ActionServlet接收到的Request委派給相應的Action處理。在業務層中，管理服務組件的Sprin

53、g IoC容器負責向Action提供業務模型(Model)組件和該組件的協作對象數據處理(DAO)組件完成業務邏輯，并提供事務處理、緩沖池等容器組件以提升系統性能和保證數據的完整性。而在持久層中，則依賴于Hibernate的對象化映射和數據庫交互，處理DAO組件請求的數據，并返回處理結果。 采用上述開發模型，不僅實現了視圖、控制器與模型的徹底分離，而且還實現了業務邏輯層與持久層的分離。這樣無論前端如何變化，模型層只需很少的改動，并且數據庫的變化也不會對前端有所影響，大大提高了系統的可復用性。而且由于不同層之間耦合度小，有利于團隊成員并行工作，大大提高了開發效率。系統的技術架構如下圖所示： 圖3

54、-5 系統技術架構圖3.2 系統功能架構3.2.1 系統功能組成電信業務數據稽核系統旨在實現電信業務數據稽核的自動化和整改的流程化，提高業務稽核工作的效率和質量。因此該系統必須包含與稽核工作相關的所有功能。結合實際情況，該系統應包含以下功能：（一）業務檔案掃描管理；（二）定單稽核管理；（三）平臺數據稽核；（四）專項稽核管理；（五）整改派單管理；（六）系統管理。通過初步分析，系統大致由業務檔案掃描模塊、定單稽核模塊、專項稽核模塊、整改派單管理模塊、統計查詢模塊和系統管理模塊幾個子系統組成。由以上分析，我們獲得系統的功能架構圖，如圖3-6所示 圖3-6 系統功能架構圖第4章 系統詳細設計詳細設計階段是為每個模塊完成的功能進行具體的描述，要把功能描述轉變為精確的、結構化的過程描述。詳細設計階段常用的描述方式：流程圖、N-S圖、PAD圖、偽代碼等。4.1 系統建模4.1.1 系統的整體模型結構要完成聯通電信業務數據稽核系統的設計，必須先了解聯通業務系統的整體模型結構，該系統的整體模型結構如圖4-1所示：圖 4-1 聯通業務系統的整體模型結構圖由上圖可以看出，ESS、BSS系統是聯通核心業務系統，業務數據稽核管理系統從ESS系統的文件接口取得定單信息，從BSS備份庫中取得業務數據，從固網交換平臺和