【正文】 對企業(yè)初步分級， 制定 新認領企業(yè)的巡查計劃， 在預警管理模塊中給予提醒 。 收費管理 從所長、副所長確定費項收取的標準開始，收費員根據(jù)上級制定的各類收費標準，執(zhí)行收費業(yè)務，每一次收費，需要指定 使用的發(fā)票號，從收費員的發(fā)票庫存表里關聯(lián)無誤后，打印發(fā)票。如因特殊原因需要對管理費定額作調整的， 應由收費員上報至所長或者副所長，對管理費額度進行修訂。根據(jù)上述場景描述，可 分析 用例圖元素 如下： 定費 參與者有 工商所所長、副所長、管理員，定費管理員 角色是對具體領導的一個泛化 通過分級定費審核，避免前期因工作人員自行定費而導致的定費標準不統(tǒng)一，定費過程不規(guī)范，缺乏有效監(jiān)管的問題。 本系統(tǒng)由如下幾部分組成： 票據(jù)分發(fā) 、票據(jù)查詢、票據(jù)統(tǒng)計、票據(jù)維護。 經(jīng)與各級財務、工商所討論需求，初步細化用例有省局票據(jù)登記、市局票據(jù)發(fā)放、市局票據(jù)登記、地方票據(jù)錄入、分局票據(jù)發(fā)放、分局票據(jù)領用、票據(jù)關聯(lián)、查詢統(tǒng)計。市局票管員 按全市調度計劃把票據(jù)分號段下發(fā)到各分局 ，并保存票據(jù)的發(fā)放信息 。工商所收費人員在收費之前，先領用 票據(jù) ，收費時先獲取當前使用的發(fā)票信息，然后進行發(fā)票打印。 167。 19 167。 在主頁上，利用色 彩來突出顯示重要的事項。為了便于快速裝載，此站點將盡量少用照片和其它圖像。 個性化元素 ， 用 戶 頁面的頂部由 當前登陸 用戶 姓名 及所屬單位 組成。 167。通常 峰值訪問量 20 的計算 按照 80%的人在 20%的工作時間 里處理業(yè)務，那么系統(tǒng)的峰值訪問量為：1500 人 *45 頁 *80%/（ 8 小時 *3600 秒 *20%） ≈ 頁 /秒。 各工商所的 日常監(jiān)管巡查信息 集中 反饋 到市局。濰坊市工商局還有一個現(xiàn)實情況就是在金管工程數(shù)據(jù)集中后，各縣里原業(yè)務處理服務器被閑置，也造成資源浪費。 22 業(yè) 務 內(nèi) 網(wǎng)市 局市 局 中 心 數(shù) 據(jù) 庫市 局 綜 合 監(jiān) 管 執(zhí) 法 服 務分 局分 局 綜 合 監(jiān) 管 執(zhí) 法 數(shù) 據(jù) 庫分 局 、 工 商 所 綜 合 監(jiān) 管 執(zhí)法 服 務分 局分 局 綜 合 監(jiān) 管 執(zhí) 法 數(shù) 據(jù) 庫分 局 、 工 商 所 綜 合 監(jiān) 管 執(zhí)法 服 務分 局 用 戶工 商 所 用 戶市 局 用 戶 圖 31系統(tǒng)結構圖 如上圖所示，市局部署服務器，完成數(shù)據(jù)的集中和統(tǒng)計功能；分局和所業(yè)務耦合比較緊密，則在分局 集中 部署一臺服務器，工商所通過業(yè)務網(wǎng)絡接入分局完成個體登記、 企業(yè)認領、巡查反饋、收費、票據(jù)管理等工作。 167?？筛鶕?jù)單位時間內(nèi)運行的各項業(yè)務總數(shù)以及辦理一筆業(yè)務所需打開的頁面數(shù)，測算應用信息處理量，市局服務器為 次頁面訪問 /分鐘 ，分局服務器為 32 次頁面 /分鐘 。峰值考慮數(shù)據(jù)處理 80%的認領在 20%的工作時間內(nèi)完成。 市局 5 秒頁面訪問量為 5/60，完成全部傳輸所需要的信息流量為 15KB58/60 秒 ≈ 232Kbps；分局5 秒頁面訪問量為 325/60， 完成全部傳輸所需要的信息流量為15KB3258/60 秒 ≈ 320Kbps。每年新增、變更、注銷的變化量約占總數(shù)的 20%，計 萬戶。 總數(shù)據(jù)量為 +=， 個體戶數(shù)目前有 14 萬戶，計算方 式與企業(yè)相同，共計 ， 上線后三年內(nèi)總數(shù)據(jù)量約為 +=。 市局服務器存儲運行內(nèi)資、外資、私營、市場、合同等核心業(yè)務數(shù)據(jù)，各分局辦理業(yè)務統(tǒng)一聯(lián)到市局服務器上處理 。省局“金管”工程二期數(shù)據(jù)集中后，各分局前期投資購買的十七臺業(yè)務服務器被閑置。目前濰坊市工商局核心業(yè)務服務器存儲和運行著工商綜合業(yè)務系統(tǒng) 18 套業(yè)務子系統(tǒng) 全部數(shù)據(jù)，服務器壓力較大。提高了數(shù)據(jù)存儲的安全性。而票據(jù)財務數(shù)據(jù)查詢時，市局通過 SQL Server 的 linked server 直接連接到各分局實時查詢。 分局利用現(xiàn)有業(yè)務服務器完成工商所綜合監(jiān)管。 存儲的 實現(xiàn)方案如圖 32： 市 局 數(shù) 據(jù) 庫分 局 數(shù) 據(jù) 庫磁 帶 庫工 商 系 統(tǒng) 業(yè) 務 網(wǎng) 絡分 局 數(shù) 據(jù) 庫分 局 數(shù) 據(jù) 庫全 市 企 業(yè) 基 礎 信息 、 認 領 信 息 、 個體 登 記 信 息 、 監(jiān) 管巡 查 信 息 、 票 據(jù) 管理 信 息 , 三 年 內(nèi) 數(shù) 據(jù)量 約 為 1 1 9 . 5 G B本 轄 區(qū) 所 有 工 商 所 認領 企 業(yè) 基 本 信 息 、 個體 管 理 信 息 、 巡 查 信息 、 財 務 信 息 。由于數(shù)據(jù)存儲集中在系統(tǒng)中心，所以數(shù)據(jù)統(tǒng)計分析匯總的工作以及數(shù)據(jù)備份的工作可以由市局信息中心集中進行，便于保障數(shù)據(jù)的安全性，加強信息資源的重利用。 實現(xiàn)災難備份。能充分利用現(xiàn)有設備資源，節(jié)約投資。結構如上圖。 服務器 以及存儲方案的選擇應 考慮到設備的穩(wěn)定性、可擴展性 以及 高性能 ，同時最大程度保護前期投資 。 每戶企業(yè)身份基礎信息總存儲量為 20KB＋ 20 KB＋ 20 KB＋ 5 KB＋ 30 KB＋50KB＝ 145KB。根據(jù)統(tǒng)計，全 市 現(xiàn)有各類企業(yè)25 萬戶，其中開業(yè)公司 17 萬戶。 每次認領對企業(yè)存在狀態(tài)， 公司經(jīng)營狀態(tài)、 認領狀態(tài)，所處地段進行多次驗證查詢操作，對于材料存在問題駁回處理的企業(yè)還要多次進 行這樣的驗證查詢操作，按平均每戶企業(yè)共 3 次查詢計算，每次查詢按平均涉及 3 個 WEB 頁面訪問估計，則 經(jīng)濟戶口部分的 信息處理量為 33≈ 次頁面訪問 /分鐘。下面 以經(jīng)濟戶口 功能模塊 為例說明測算方法 。 工商所綜合監(jiān)管執(zhí)法系統(tǒng)的硬件架構設計包括服務器選型 、 通訊 鏈路 設計和安全架構設計 ，要求達到高效穩(wěn)定的要求，保證數(shù)據(jù)安全和鏈路暢通，同時 23 避免出現(xiàn)單點故障。如市局服務器一旦出現(xiàn)單點故障，也不影響各縣市局本地業(yè)務的運行。 而分局和工商所共同完成對個體工商戶登記的受理和審核，完成專項巡查計劃的派發(fā)和巡查反饋，完成票據(jù)的分發(fā)領用繳銷工作。 因此，采用集中部署比較合適。 系統(tǒng)結構 設計 工商所綜合監(jiān)管系統(tǒng)的開發(fā)目的 是為了完善工商所的個體工商戶登記管理，建立規(guī)范的全市企業(yè)屬地管理機制，提取各地監(jiān)管巡查信息以進行信用等級評估，增強對工商所的收費以及財務票據(jù)的管理。 濰坊市工商系統(tǒng)工作人員中，需要使用本系統(tǒng)處理業(yè)務的主要部門有市局、分局的企業(yè)注冊局、財務科、消保科以及所有工商所、市場管理辦公室。 在正文區(qū)顯示當前用戶待辦事項與警示。此站點將不使用任何 JavaScript 翻滾或動畫 ，保證每頁容量不超過 15KB。所有的正文文字都是黑色，而表標題對于各種背景顏色都為白色 ，通知與警示用紅色 。 167。除了收費管理和票據(jù)管理外， 本系統(tǒng)還應包括企業(yè)管理和巡察監(jiān)管的相關內(nèi)容 。 票據(jù)查詢功能實現(xiàn)對票據(jù)管理人員及票據(jù)使用人員的無紙化查詢及電子臺帳等， 具體查詢項目有 票據(jù)數(shù)據(jù)登記查詢、個人票據(jù)庫存查詢、單位票據(jù)發(fā)放查詢、票據(jù)作廢情況查詢、票據(jù)作廢情況查詢、非定額票據(jù)繳銷查詢、 定額票據(jù)繳銷查詢、個人票據(jù)領用查詢、個人票據(jù)未繳銷查詢、票據(jù)發(fā)放單位庫存查詢、票據(jù)使用單位庫存查詢、票據(jù)收費情況查詢、個人票據(jù)已使用未繳銷查詢 。 18 各分局票管員從市局領取本號段的市局財政票據(jù)，同時進 行地方票據(jù)錄入登記 ，并分發(fā)到所 ，保存發(fā)放信息 。 綜上所述，構建票據(jù)流轉的用例如圖： 票據(jù)發(fā)放省財政票據(jù)登記市局票據(jù)管理員市局票據(jù)發(fā)放 in c l u d e 市局發(fā)放票據(jù)登記地方票據(jù)錄入分局票據(jù)管理員分局票據(jù)發(fā)放 in c l u d e 分局發(fā)放票據(jù)登記基層單位票據(jù)管理員票據(jù)使用人員票據(jù)領用各項收費設置當前正在使用票據(jù)票據(jù)關聯(lián)相關查詢統(tǒng)計查詢及統(tǒng)計用戶分管領導財務科領導 分管局領導 圖 2－ 5 財務票據(jù)管理用例圖 如上圖所示， 票據(jù)分發(fā)過程分為省、市、縣、所四級管理體制。分析過程如下： 參與者有市局票管員、分局票管員、基層單位票管員、票據(jù)使用人員、分管局領導、財務科領導。 功能類別 功能名稱、標識符 描述 個體定費 個體定費 .1 待定費個體工商戶檢索 個體定費 .2 察看個體工商戶詳細信息 個體定費 .3 個體工商戶定費 個體定費 .4 個體工商戶減免工商費 定費調整 定費調整 .1 根據(jù)注冊號、名稱、負責人、經(jīng)營場所、管片、行業(yè)批量檢索已定費個體戶信息 定費調整 .2 調整單戶管理費定額 定費調整 .3 批量調整管 理費定額 名稱、標識符 個體定費 .1 功能描述 根據(jù)注冊號、名稱、負責人、經(jīng)營場所、管片、行業(yè)批量檢索未定費個 16 體戶信息 操作者 定費管理組人員 優(yōu)先級 高 輸入 注冊號、名稱、負責人、經(jīng)營場所、管片、行業(yè) 輸出 分頁顯示的 未定費個體戶 列表 成功保證 提取信息成功 非功能要求 業(yè)務規(guī)則 分頁顯示 設計約束 名稱、標識符 個體定費 .2 功能描述 察看個體工商戶詳細信息 操作者 定費管理組人員 優(yōu)先級 高 輸入 選定個體工商戶 輸出 個體工商戶登記信息 頁面， 基本情況、經(jīng)營 者信息、審批證件、變更事項、審核意見 成功保證 打開個體工商戶登記信息頁面 業(yè)務規(guī)則 說明必須遵循客戶方面的業(yè)務規(guī)則 設計約束 說明對下一步的設計工作的要求 167。同時考慮到所里工作實際情況，所長經(jīng)常指定一個信息管理員具體負責系統(tǒng)維護工作。 圖24 給出收費管理的用例圖 ： 工商所長工商所副所長信息管理員發(fā)票關聯(lián)檢索待定費列表察看登記信息非定額收費修改定費修改管理費減免定額收費 i n c l u d e 非定額罰款 i n c l u d e 打印發(fā)票非定額收費 i n c l u d e 定費待收費信息定額收費修改定費管理員收費員用戶登錄市局財務人員收費查詢分局財務人員收費統(tǒng)計 圖 24 收費管理用例 下面以定費管理 部分為例說明分析過程： 當轄區(qū)內(nèi)有新的個體戶辦理了開業(yè)登記手續(xù)以后， 工商所 的 所長、 副所長檢索待定費人員列表，逐個查閱 個體戶基本登記信息以及 基本 經(jīng)營情況， 根據(jù) 15 有關規(guī)定以及業(yè)戶的實際行業(yè)類別、經(jīng)營規(guī)模確定管理費額度 。 本文中， 以 收費管理、 票據(jù)管理、 系統(tǒng) 管理三部分 為例 進行 用例 分析 ，其它部分做一 概述 ： 167。各業(yè)務之間關系如圖 23 所示： 13 圖 23業(yè)務關系圖 市局綜合監(jiān)管執(zhí)法服務器從省局業(yè)務系統(tǒng)中提取數(shù)據(jù)后，下發(fā)給工商所人員。 167。 掌握需求調研頻度，若需求基線符合要求， 則進入設計編碼階段，然后 返回到 用戶再次確定需求 ， 如此迭代 多次，直到 需求 分析使雙方滿意為止。 規(guī)范統(tǒng)一業(yè)務流程，不明確不統(tǒng)一的業(yè)務流程由局長協(xié)調，確定負責單位，制定全市統(tǒng)一的業(yè)務處理流程。 需求不斷變更，項目邊界難以確定 前三項困難主要來自工商所，而在局機關這樣已習慣于信息化處理的部門相對需求調研的環(huán)境要好得多。 需求的獲取 相對于工商系統(tǒng)局機關的工作人員來說，工商所的工作人員的日常事務處理范圍較廣，隨機性更大，人為控制因素更強，更加習慣于人工處理業(yè)務，相對信息設備配置條件也較差。 在本項目中，需求管理的目標就是確切了解本系統(tǒng)使用者 ，包括 市局、分局相關科室人員、工商所工作人員的需求，找出能滿足所有使用者的最佳解決方案。 從前期 工商系統(tǒng) 的電子政務項目的實施經(jīng)驗來看，電子政務系統(tǒng)失敗的主要風險經(jīng)常不是來自于技術實現(xiàn)風險，而是 在于開發(fā)者對工商業(yè)務缺乏了解， 對使用者的實際需求認識不清，不能從各個使用者提出的 龐 雜的意見建議 集中提取出統(tǒng)一的、具有靈活性、規(guī)范性的工作流程，進而形成系統(tǒng)實現(xiàn)。整個開發(fā)周期如圖 22 所示： 圖 22工程進度計劃 167。移交階段的需求變更已經(jīng)比較少，在本階段的制品除了可試運行的產(chǎn)品外，還進行了部署計劃的編制和培訓計劃、培訓文檔編寫的初期工作。 構造階段的主要工作是 管理資源與控制過程 ， 開發(fā)與測試組件 ，并隨時對開發(fā)成果 進行評估 。 細化階段 的目標是 進一步細化需求，并設立 系統(tǒng)構架基線，為 順利過渡到構造 階段打下堅實的基礎。 在本項目中，比較重要的工作是前兩項，也就是業(yè)務人員和開發(fā)人員經(jīng)過對同類產(chǎn)品調研，經(jīng)對項目邊界和詳細業(yè)務需求有一個比較清 9 晰的共識的過程。 為此， 項目 按照 RUP 迭代模型實現(xiàn)開發(fā) ，采用 用例驅動 、 以構架為中心 和迭代開發(fā)的方法， 一方面對項目總體情況進行掌握，另一方面將項目分解為多個子任務 和一系列迭代過程 。 項目開發(fā) 過程 軟件開發(fā)有 瀑布模型 、 快速原型模型 、迭代模型、螺旋模型等開發(fā)模式。工商所根據(jù)巡查計劃有重點地巡查所屬企業(yè)，并反饋巡查信息到上級主管部門。 個體登記管理流程由工商所人員受理個體戶開業(yè)申請、變更申請、停業(yè)申請、 注銷申請，初審后送交分局企業(yè)注冊局審核，審核通過后返回工商所進行相應業(yè)務處理，打印營業(yè)執(zhí)照 。 開發(fā)財務監(jiān)管和 個體收費系統(tǒng)，實現(xiàn)定費，收費，票據(jù)管理的統(tǒng)一，方便上級部門審查和監(jiān)管。 系統(tǒng)概述 167。 第四章 是 詳細設計 部分，通過基于 RUP 的分析