1、散裝汽油購銷實名登記治理信息系統項目技術方案背景近年來，國內相繼發生公交車、醫院等公眾場所縱火案。該類案件中，散裝汽油成為犯罪分子實施暴力突擊和個人暴力犯罪的重要工具。因此，加油站點散裝汽油的銷售安全治理工作刻不容緩。2014年3月公安部下發關于迅速采取超常措施建立完善嚴控嚴查散裝購、銷汽油制度的通知，強調：對能夠散裝購買汽油的，加油站和加油員要監督加油全過程，注意發覺、及時報告可疑情況，并如實登記散裝購買汽油人員的姓名、身份證件號碼和購買數量、用途等。散裝汽油體系包括單位、個人生產、生活需要。但近年來，利用汽油實施暴恐突擊犯罪的威脅進一步凸顯，但隨意銷售、對購買人信息掌握不全及汽油流向不明等

2、問題卻成為制約散裝汽油銷售管控工作有效開展的瓶頸。為此，按照公安部的工作要求，為了實行了散裝汽油銷售實名購買、實情登記、實時傳輸的“三實”舉措，打算研發“散裝汽油銷售治安信息治理系統”，構建“購買登記、信息采集、傳輸比對、落地查人”的管控工作模式，實現對散裝汽油購買人及流向的實時、有效治理。 實名登記制度規定，對確因生產、科研、生活等需要購買散裝汽油的，一律實行實名登記制度。不能提供有效身份證件的，加油站一律拒絕銷售并解釋講明；對其中的可疑人員，立即向轄區派出所報告，由派出所進一步核查。 隨著科技進展，越來越多的重要信息數據資源需要進行集中收集，關于重要數據資源用于公安機關進行資源的綜合開發利

3、用，充分發揮數據資源的效用。通過對可疑數據資源的挖掘與研判分析，提高公安機關偵查破案的效率，更好地服務經濟社會進展，因此開發和應用一套治安治理信息系統平臺勢在必行。建設任務建立散裝汽油銷售數據采集治理支撐系統：實現社會散裝汽油銷售信息進行采集；建立對可疑人員的信息碰撞機制，擴大社會信息比對范圍。且實現實時監督治理，監控散裝汽油銷售公司進出物資，確保全省治安良好和企業財產的安全保障。 建立散裝汽油銷售企業安全監測：實現對散裝汽油銷售企業的安全監測。 建立散裝汽油銷售從業人員的信息篩查，實現對散裝汽油銷售企業從業人員的安全監測。 建立一鍵報警體系，實現重點單位安全體系的完善和補充。 建立內網數據應

4、用支撐系統：實現對所歸集散裝汽油銷售信息的比對、預警、以及研判分析，并通過部門間共享平臺提供給公安各業務系統進行資源信息的綜合查詢。 系統硬件環境的搭建：依照本次系統運行環境設計，對項目整體運行環境所需服務器、存儲等硬件設備進行集成。建設技術要求系統應采納三層體系架構體系。 采納成熟的技術及產品實現數據的采集、歸集及比對分析。 要緊業務辦理界面不能下載非安全的控件，控件與數據庫無直接交互操作。 必須保證系統具有開放的體系與接口，客戶端支持跨平臺運行，支持Linux、Unix、Window等主流的操作系統及Android等主流移動終端操作系統。 采納可靠的安全技術，安全保密體系必須達到國標、部標

5、標準。 必須充分考慮目前我單位現有的軟、硬件資源的可利用性，如：充分利用現有服務器硬件、操作系統、數據庫進行方案部署，實現與現有的各治安信息治理系統共享用戶審核、權限分配、日志記錄與分析等，保證數據的互聯互通，高效利用和發揮現有資源的優勢。 系統必須具備有用性、可靠性、高擴展性、先進性、安全性、可維護性和操作友好性。總體架構項目建設內容互聯網應用平臺 互聯網數據庫建設 外網數據庫是外網資源數據采集匯總的第一站，為了今后的各類數據采集匯總，外網數據庫建立需遵循以下標準： 統一的數據標準 外網數據庫建設需符合國際、國內、行業和公安部相關標準，包括數據采集項、數據字典、數據接口規范等等。建立完成統一

6、的信息接入標準，為今后各類信息接入提供統一標準。 關系型數據庫 采納現主流數據庫系統如Oracle、SqlServer、MySql、Sybase、DB2、DM、Kingbase、MaxDB、InfoMix、PostgreSql等。 提供與我單位原有信息的數據對接，幸免重復建設、重復投入。 散裝汽油銷售信息采集門戶治理 兼容PC端、手機端、平板端操作。 支持可靠的認證治理登錄。 支持前臺用戶修改認證密碼。 提供用戶登錄日志展示與分析。 提供用戶登錄日志全周期檢索。 支持相關信息公布治理 提供統一身份認證治理平臺，能將互聯網應用各平臺進行無縫單點身份認證處理。 通知通告治理兼容PC端、手機端、平板

7、端操作。 提供通知通告、協查通報等信息的公布、刪除和修改。 提供企業和從業人員、警員對通知通告的閱讀記錄。 通知通告治理須支持可視化富文本編輯，能夠方便的在線編輯通知通告的樣式、內容。 提供與我單位現有信息系統的接口，實現與現有信息系統的通知通告的數據集成、共享、轉發。 從業企業信息治理 兼容PC端、手機端、平板端操作。 提供企業信息的增加、刪除、修改查詢功能。 支持平臺治理員對從業企業信息治理和維護。 提供從業企業的活躍度監測，幸免銷售企業不按規定登記散裝汽油銷售。 從業人員治理兼容PC端、手機端、平板端操作。 提供企業從業人員治理功能，支持從業員人信息增、刪、改等操作。 支持數字采集設備的

8、數據采集，例如二代身份證讀取器，手機/平板電腦方便快速錄入人員差不多信息。 能對人員在企業的入、離職等其他信息進行維護。 一鍵報警 兼容PC端、手機端、平板端操作。 提供報警人信息治理，包括報警人姓名、聯系方式、報警內容。 與報警信息進行處理，任何報警信息都必須有對應的處理信息，提供報警信息治理功能 散裝汽油銷售治理 兼容PC端、手機端、平板端操作。 提供購買人信息治理，包括購買人姓名、身份證號碼、聯系方式、購買時刻購買油量、購買用途等信息的維護； 與購買信息進行對應關系處理，任何購買信息都必須對應有購買信息。提供購買歷史治理功能。 各客戶須支持智能讀卡設備對二代身份證的讀取功能，幸免信息錄入

9、的榮譽復雜。 散裝汽油銷售信息分析 針對散裝汽油銷售信息采集的采集數據,提供配套的統計分析治理功能，以滿足散裝汽油銷售處理日常的治理需要，提升企來對系統的使用興趣。該子系統另外要包含公安內網應用平臺的企業治理和平臺治理功能。 企業信息多維度分析。 企業從業人員多維度分析。 企業車輛多維度統計治理。 購買信息多維度治理等統計分析功能。 警情通知治理兼容PC端、手機端、平板端操作。 支持警情的閱讀操作。 支持警情的轉發操作。 支持警情的批示操作。 處警治理 兼容PC端、手機端、平板端操作。 提供處警功能，包括處警警員姓名、聯系方式、出警時刻、處理結果等信息的維護。 與報警信息進行核對，任何出警記錄

10、都必須有相對應的信息記錄 提供出警信息治理功能。 油區重點部位巡查 兼容PC端、手機端、平板端操作。 支持重點單位、部位的巡查功能，要求支持巡查地理信息、巡查結果、巡查照片上傳及其地理信息的標注。 支持重點單位、部位的自動巡查考核，對不合格的巡查記錄自動標注。 2.4.1.4.7油區重點部位地理信息采集子系統 兼容手機端、平板端操作。 支持對全省油區重點部位的地理信息采集，要求采集的地理信息精度誤差不超過10米。 支持與重點部位巡查結果的數據比對，自動篩選出不合格的巡查記錄。 分局信息治理 兼容PC端、手機端、平板端操作。 支持分局單位信息的增加、修改、刪除、查詢功能。 提供單位治理員對本單位

11、信息的維護及維護記錄。 提供單位的授權治理。 支持對現有信息平臺的引用，盡可能的幸免重復建設。 警員治理 兼容PC端、手機端、平板端操作。 支持警員信息的增加、修改、刪除、查詢功能。 支持單位治理員對警員信息的維護功能。 提供警員對自身信息的維護治理功能。 提供單位治理員對單位警員的密碼重置功能。 提供警員對自己密碼的修改等功能。 提供統一身份認證治理平臺，能將互聯網應用各平臺進行無縫單點身份認證處理。 支持對現有信息平臺的警員信息的引用，利用現有警員賬號進行登錄。 授權治理 兼容PC端、手機端、平板端操作。 支持可靠的授權治理子系統。 支持精細的授權治理功能，下鉆到每個用戶在每個模塊的每個功

12、能上的權限操縱治理。 支持分時授權治理功能，針對特定的單位、用戶進行分時授權治理。 支持授權例外治理功能，支持特定組、角色、單位的特定授權下的多樣化例外授權。例外授權可精細操縱到角色、用戶粒度。 支持現有平臺的授權體系集成，結合我單位現有用戶治理的授權體系對本系統進行授權治理。 內網應用平臺 散裝汽油銷售治理系統公安網部分要緊功能體現在對互聯網用戶采集過來的數據統計、分析、研判并結合公安內網的相關數據進行二次研判、比對、分析等等功能。為充分利用散裝汽油銷售業信息對公安的實戰工作提供有效的支持。該平臺的企業治理子系統和平臺治理子系統功能在互聯網應用平臺上部署可應用。 公安網數據資源庫 數據資源庫

13、是一個信息、數據收集、整合、分類、標引組織，完成由數據上升為情報信息的過程，通過匯合整合公安內外部情報信息資源，以結構化或非結構化數據形式建成情報信息綜合數據庫，為建設情報綜合平臺和開展各種情報信息應用提供數據基礎。綜合數據庫要緊體現為在現有的數據信息的基礎上進行擴展，一方面保證一期的建設成果，另一方面通過擴展，能夠為后續的更多應用的開展提供更好的數據支持。 同時可對公安外網采集到的數據進行清洗、轉換，并按照規定的數據標準和格式進入內網進行重組和分類存儲。同時要求在公安內網建立信息比對資源庫，對所歸集的資源信息與布控人員進行比對，形成相應人員、物品比對庫（比如在逃人員庫、違法犯罪嫌疑人員庫、布

14、控信息庫）。 智能分析 為提高數據質量、數據利用率以及最大限度的發揮已有數據的作用，系統需要對平臺內的全部資源進行多角度、多維度的綜合智能分析。讓不同的用戶從不同的角度全面了解現有散裝散裝汽油銷售業采集信息的情況，以及采集的數據所發揮的作用。通過不同的數據建模發覺不同的治安內問題，例如當前最突出的二手臟物交易、兩搶一盜案件高發地區。作案高危嫌疑人等。 企業信息分析 提供企業維度分析，按地域、按管轄單位、按法人、按企業名稱等進行檢索與統計。并支持下鉆到明細。 購買信息分析 提供購買人姓名、身份證、散裝汽油銷售企業名稱、身份證等相關信息查詢與統計，并支持下鉆到明細功能。 布控信息分析 提供按布控申

15、請人、申請機構、布控狀態、布控目標信息、布控結果等信息的查詢統計功能，并支持下鉆到明細。 布控預警信息分析 提供按預警對像、如身份證，手機串等，預警反饋狀態，預警地域、預警對像的多維度分析統計功能，并支持下鉆到明細數據。 布控治理 民警用戶可通過布控治理子系統發起在線申請、審批、公布等在線操作流程，同時支持多級審批，系統能支持審批條件預設置，在用戶申請初期即完成部分審批預處理，提高后期審批通過率。 支持人員、銷售油量布控，人員布控時需與公安部請求服務完成人口信息核實，并提醒申請人異常信息 支持布控范圍的設定，在設定范圍要進行布控治理。 布控申請支持預警模式設置。 支持布控審批時的批量審批。 支

16、持布控到期自動撤控，布控到期前可進行人工撤控、續控等。 預警治理 基于散裝汽油銷售業信息采集子系統提供給公安內網的數據資源庫，結合公安部提供的在逃人員庫、全國違法法犯罪人員庫以及布控治理子系統提供的相關信息，進進行預警處理， 建立布控人員庫，包括布控治理系統提供的人員信息，公安部相關布控人員信息，各專業警種布控人員信息。 建立預警比對模型，給合布控人員庫、布控物品庫的相關信息以及依照布控子系統的布控需求，產生不同的預警信息。 依照不同的設定模式對預警信息進行自動分發處理 同時對不同的預警接收人提供不同的預警簽收反饋功能。 預警信息的產生以及預警信息的反饋均需要滿足公安部的相關要求。能與公安部情

17、報平臺進行數據交換處理。 基于預警公布、反饋以及相關處理的流程之上，提供預警對像的相關信息展示，如活動軌跡。散裝汽油銷售軌跡等。并提供預警信息的多維度分析，給公安部門的防、管、控、打行動提供決策支持。 基于全國七類重點人員的預警，提供與公安部重點人員檔案系統的對接。 企業治理該子系統要緊是針對企業單位信息、企業從業人員信息、企業數據采集情況進行相關治理與分析。 結合互聯網上的散裝汽油銷售信息采集子系統提供的數據，完成對散裝汽油銷售業的物品分析治理。 同時對散裝汽油銷售企業上傳的數據進行多維度分析，產生對散裝汽油銷售企業的自動巡檢提示，支持對散裝汽油銷售企業的處罰工作。 提供企業單位信息的維護；

18、以及治理用戶授權等；提供企業維度分析，按地域、按管轄單位、按法人、按企業名稱等進行檢索與統計。并支持下鉆。 平臺治理通過完整、嚴密的用戶角色體系設計，實現功能模塊的權限操縱。通過按崗位設計用戶實現嚴格的數據訪問范圍操縱。該模塊能夠 統一身份證證 提供統一身份認證平臺，對其他子系統提供完整的單點認證接口，實現統一身份認證功能。 分級授權 提供分級授權治理、支持權限分級治理，多級授權。為減少最高級治理員授權工作。 日志治理 提供系統操作日志治理等功能。 用戶治理 對訪問系統的用戶帳號進行治理，提供帳號的添加、刪除、修改、查詢功能，為帳號批量導入提供模板。 角色治理 提供立體多維角色權限治理，能夠對

19、功能權限、數據權限進行立體的治理，對組織、用戶、角色、功能等各類資源進行統一、分級治理，統一治理可將各類資源進行集中式治理，分級治理可將權限下放到部門、子部門一級的治理員。授權方式與傳統的對用戶、對角色授權不同，是真正基于策略的靈活的授權方式，可對任何資源進行授權，授權時，可對主動資源（授權資源）與被動資源（被授權資源）進行級聯和過濾。同時支持將角色進行列表的導出。 權限治理 提供對用戶進行角色授權以及功能的添加、刪除、修改、查詢。實現4級權限治理。 基礎信息治理。 提供企業單位信息、法人信息與設置等基礎信息的添加、刪除、修改、查詢。 用戶登錄模塊 提供用戶登錄、密碼修改、注銷、USB加密狗注

20、冊等功能。 系統安全保障 安全保障目標 通過整體安全體系規劃，綜合運用各種安全技術和手段。要求達到的安全目標為： 靜態安全目標：包括整個系統的物理環境、系統軟硬件結構和可用的信息資源，保證系統實體平臺安全。 動態安全目標：提升系統的安全軟環境，包括安全治理、安全服務、安全意識和人員的安全專業素養。 安全體系設計 依照系統安全保障的目標，投標人應從安全治理、應用系統安全設計（包括權限認證、用戶認證、日志審計等多個方面）、數據安全與備份、網絡安全、平臺安全等多個方面來考慮，并進行相應的描述。 要求關于不同的數據，采納不同的加密政策。關于敏感數據，為防止數據庫治理員查看數據和其他的意外情況發生，所有

21、保存到數據庫的關鍵數據通過128位的RSA算法或者其他高級加密算法進行加密，保證數據在保存點的安全性。要求投標人對數據加密進行詳細設計。 內外網的數據交換安全，要求投標人結合現有安全邊界平臺，以及部門間信息共享平臺的架構對此次散裝汽油銷售信息的歸集與交換進行詳細設計。 數據庫安全 系統安全性策略 (1)治理數據庫用戶 數據庫用戶是訪問數據庫信息的途徑，因此，應該專門好地維護治理數據庫用戶的安全性。按照數據庫系統的大小和治理數據庫用戶所需的工作量，數據庫安全性治理者可能只是擁有create，alter，或drop數據庫用戶的一個專門用戶，或者是擁有這些權限的一組用戶，應注意的是，只有那些值得信任

22、的個人才應該有治理數據庫用戶的權限。 (2)操作系統安全性 A）數據庫治理員必須有create和delete文件的操作系統權限； B）一般數據庫用戶不應該有create或delete與數據庫相關文件的操作系統權限； C）假如操作系統能為數據庫用戶分配角色，那么安全性治理者必須有修改操作系統帳戶安全性區域的操作系統權限。 用戶的安全性策略 (1)一般用戶的安全性 關于那些用戶專門多，應用程序和數據對象專門豐富的數據庫，應充分利用“角色”那個機制所帶的方便性對權限進行有效治理。關于復雜的系統環境，“角色”能大大地簡化權限的治理。 (2)終端用戶的安全性 須針對終端用戶制定安全性策略。例如，關于一個

23、有專門多用戶的大規模數據庫，安全性治理者能夠決定用戶組分類，為這些用戶組創建用戶角色，把所需的權限和應用程序角色授予每一個用戶角色，以及為用戶分配相應的用戶角色。當處理專門的應用要求時，安全性治理者也必須明確地把一些特定的權限要求授予給用戶。能夠使用“角色”對終端用戶進行權限治理。 應用安全 應用審計 應用系統日志審計功能參照公安部相關的應用系統審計標準，達到相關標準規范要求。 權限治理 通過完整、嚴密的用戶角色體系設計，實現功能模塊的權限操縱。通過按崗位設計用戶實現嚴格的數據訪問范圍操縱。 應用功能的權限。系統的應用功能的權限設定包括建立完整的業務功能描述體系，把信息系統應完成的功能進行明確

24、的描述；建立應用功能權限描述體系，描述用戶與具體業務功能的關系。 業務數據的權限。 與業務功能權限相似，系統應包括：完備的業務數據描述體系，描述系統的需要權限限定的數據。建立業務數據權限描述體系，描述用戶與具體業務數據的權限關系。 日志監控 系統日志 生成系統日志包括以下幾方面內容： 創建、刪除用戶 為了防止通過臨時創建的用戶做違規操作，在操作日志中記錄用戶創建和刪除的詳細信息。 操作日志 記錄每個用戶的操作信息，供事后核查審計。 登錄退出 為了事后追查安全問題的緣故，登錄退出在日志中保存了詳細的信息。 授權變更 為了幸免違規權限操作，授權變更在日志中保存了詳細的信息。 查詢分析 為了幸免相關

25、交易信息和個人隱私數據的外泄，對查詢的數據進行日志記錄，能夠反跟蹤相關數據查詢記錄內外網各功能模塊可依照實際需求情況，調整內外網部署設計。項目實施項目團隊組織團隊組織架構圖一個工程項目能夠順利地實施，成功地完成，依靠我方與用戶專門好的溝通和緊密的合作。為保證本項目的順利進行，實現優質高效的目標，在項目啟動時期將聯合成立項目領導小組，全面負責系統建設中的各項任務。項目領導小組下設項目經理及由項目經理領導的軟件開發組、質量治理組、測試組、應用實施組、商務及培訓組、維護服務組，其組織結構如下圖所示。崗位職責講明項目領導小組項目領導小組是項目整個生命周期的最高領導者，由雙方項目主管領導組成，以定期例會

26、的形式工作。項目領導小組的要緊任務是：規劃、組織、指揮整個項目的實施，協調各方的工作以及人員調配，協調和解決雙方合作中出現的問題，操縱整個工程進度，保證項目保質保量完成。貫徹上級主管部門對工程建設的指導意見，確定系統實施中重要業務規范和技術標準，組織評審系統總體設計方案，協調與工程實施有關的各方之間關系，對工程實施過程中出現的重大問題做出決策，對工程各時期的工作做出評估，組織工程的考核、鑒定、驗收等工作。項目經理采納項目經理負責制，由公司在公司項目經理隊伍中指定一名具備應用系統開發經驗、熟悉業務、具有項目經理資質的人擔任此工程的項目經理。要緊職責是：制定項目開發、應用實施、維護服務等各時期詳細

27、工作打算，負責資源調配，按打算執行項目；掌握、操縱項目的每個實施過程，組織系統分析、系統設計、詳細設計、系統測試、應用實施等各時期的打算和方案的評審；負責用戶現場的協調，具體解決項目實施中出現的各種情況和問題；負責項目的變化治理和風險治理，定期向項目領導小組匯報項目進展情況；項目交接治理等。軟件開發組軟件開發組成員以公司技術人員組成。要緊職責是：依照甲方的實際需求進行需求分析，設計開發方案及編寫開發文檔，完成軟件開發，滿足甲方的實際需求。負責編寫對用戶的系統治理人員、操作人員進行相關的技術培訓、應用系統操作培訓的培訓資料。質量治理組質量治理組成員由廠家1人和甲方人員組成。要緊職責是：負責制定項

28、目的質量監控治理規范及實施細則，負責項目的配置治理，負責項目文檔的治理工作，對項目實施進行全程監控，及時向項目領導小組、項目經理提交質量監控報告。測試組測試組成員由廠家2人和甲方人員組成。要緊職責是：負責項目集成測試、系統測試、初步驗收測試的測試方案、測試打算的制定、實施和測試分析報告的編制，及時向項目領導小組、項目經理提交測試分析報告報告。應用實施組應用實施組成員由廠家2人和甲方人員組成。要緊職責是：負責應用系統的安裝、調試；利用應用服務工具，通過配置、部署等方式，完成數據庫的建立，制定及實施數據維護（ETL）方案；利用應用服務工具，通過配置、部署等方式，實現應用功能。負責系統治理和監控方案

29、的制定及實施，負責應用系統的試運行、現場信息收集及反饋等工作。現場安裝、調試過程中，需要用戶配合工作。商務及培訓組由廠家商務人員、技術人員和甲方相關人員組成。其職責如下：完成項目組確定的各項商務活動，保證工程所需各項產品的按時到貨、驗收，協調雙方關系, 為系統順利實施做好配合工作；組織對用戶的系統治理人員、操作人員進行相關的技術培訓、應用系統操作培訓等。維護服務組由廠家技術人員和甲方相關人員組成。維護服務組的人員來自項目實施過程中的軟件開發人員和應用實施人員。進度打算項目從開始到安裝部署上線并通過初驗為90個日歷日，其后進入試運行期。任務名稱起止時刻工作人員預期工作成果一、整體規劃以及需求調研

30、項目現場調研及項目總體實施設計T5(T代表合同簽訂日期)需求分析員項目打算需求分析報告二、軟件任務分解系統的概要設計（T5）10設計工程師概要設計系統的開發（T510）50實施工程師系統功能模塊系統安裝部署調試數據采集、綜合庫建設（T51050）20測試工程師提交系統三、系統測試、試運行、培訓以及初驗和終驗項目初驗測試（T5105020）5測試工程師項目測試報告系統試運行（系統測試、調整、修改、試運行以及應用軟件培訓）甲方定試運行期項目經理項目培訓記錄項目驗收項目初驗后試運行期項目經理項目終驗合格證書及相關驗收文檔開發測試治理開發治理Java是一種優秀的面向對象開發語言，因此本系統的開發采納面

31、向對象的開發方法。面向對象技術是軟件技術的一次革命，在軟件開發史上具有里程碑的意義。隨著OOP（面向對象編程）向OOD（面向對象設計）和OOA（面向對象分析）的進展，最終形成面向對象的軟件開發方法OMT(Object Modelling Technique）。這是一種自底向上和自頂向下相結合的方法，而且它以對象建模為基礎，從而不僅考慮了輸入、輸出數據結構，實際上也包含了所有對象的數據結構。因此OMT完全實現了PAM沒有完全實現的目標。不僅如此，OO技術在需求分析、可維護性和可靠性這三個軟件開發的關鍵環節和質量指標上有了實質性的突破，完全地解決了在這些方面存在的嚴峻問題，從而宣告了軟件危機末日的

32、來臨。1、自底向上的歸納OMT的第一步是從問題的陳述入手，構造系統模型。從真實系統導出類的體系，即對象模型包括類的屬性，與子類、父類的繼承關系，以及類之間的關聯。類是具有相似屬性和行為的一組具體實例（客觀對象）的抽象，父類是若干子類的歸納。因此這是一種自底向上的歸納過程。在自底向上的歸納過程中，為使子類能更合理地繼承父類的屬性和行為，可能需要自頂向下的修改，從而使整個類體系更加合理。由于這種類體系的構造是從具體到抽象，再從抽象到具體，符合人類的思維規律，因此能更快、更方便地完成任務。這與自頂向下的Yourdon方法構成鮮亮的對比。在Yourdon方法中構造系統模型是最困難的一步，因為自頂向下的

33、“頂”是一個空中樓閣，缺乏堅實的基礎，而且功能分解有相當大的任意性，因此需要開發人員有豐富的軟件開發經驗。而在OTM中這一工作可由一般開發人員較快地完成。在對象模型建立后，專門容易在這一基礎上再導出動態模型和功能模型。這三個模型一起構成要求解的系統模型。2、自頂向下的分解系統模型建立后的工作確實是分解。與Yourdon方法按功能分解不同，在OMT中通常按服務（Service）來分解。服務是具有共同目標的相關功能的集合，如I/O處理、圖形處理等。這一步的分解通常專門明確，而這些子系統的進一步分解因有較具體的系統模型為依據，也相對容易。因此OMT也具有自頂向下方法的優點，即能有效地操縱模塊的復雜性

34、，同時幸免了Yourdon方法中功能分解的困難和不確定性。3、OMT的基礎是對象模型每個對象類由數據結構（屬性）和操作（行為）組成，有關的所有數據結構（包括輸入、輸出數據結構）都成了軟件開發的依據。因此Jackson方法和PAM中輸入、輸出數據結構與整個系統之間的鴻溝在OMT中不再存在。OMT不僅具有Jackson方法和PAM的優點，而且能夠應用于大型系統。更重要的是，在Jackson方法和PAM方法中，當它們的動身點-輸入、輸出數據結構（即系統的邊界）發生變化時，整個軟件必須推倒重來。但在OMT中系統邊界的改變只是增加或減少一些對象而已，整個系統改動微小。4、需求分析完全需求分析不完全是軟件

35、失敗的要緊緣故之一。即使在目前，這一危險依舊存在。傳統的軟件開發方法不同意在開發過程中用戶的需求發生變化，從而導致種種問題。正是由于這一緣故，人們提出了原型化方法，推出探究原型、實驗原型和進化原型，積極鼓舞用戶改進需求。在每次改進需求后又形成新的進化原型供用戶試用，直到用戶差不多中意，大大提高了軟件的成功率。然而它要求軟件開發人員能迅速生成這些原型，這就要求有自動生成代碼的工具的支持。OMT完全解決了這一問題。因為需求分析過程已與系統模型的形成過程一致，開發人員與用戶的討論是從用戶熟悉的具體實例（實體）開始的。開發人員必須搞清現實系統才能導出系統模型，這就使用戶與開發人員之間有了共同的語言，幸

36、免了傳統需求分析中可能產生的種種問題。5、可維護性大大改善在OMT之前的軟件開發方法差不多上基于功能分解的。盡管軟件工程學在可維護方面作出了極大的努力，使軟件的可維護性有較大的改進。但從本質上講，基于功能分解的軟件是不易維護的。因為功能一旦有變化都會使開發的軟件系統產生較大的變化，甚至推倒重來。更嚴峻的是，在這種軟件系統中，修改是困難的。由于種種緣故，即使是微小的修改也可能引入新的錯誤。因此傳統開發方法專門可能會引起軟件成本增長失控、軟件質量得不到保證等一系列嚴峻問題。正是OMT才使軟件的可維護性有了質的改善。OMT的基礎是目標系統的對象模型，而不是功能的分解。功能是對象的使用，它依靠于應用的

37、細節，并在開發過程中不斷變化。由于對象是客觀存在的，因此當需求變化時對象的性質要比對象的使用更為穩定，從而使建立在對象結構上的軟件系統也更為穩定。更重要的是OMT完全解決了軟件的可維護性。在OO語言中，子類不僅能夠繼承父類的屬性和行為，而且也能夠重載父類的某個行為（虛函數）。利用這一特點，我們能夠方便地進行功能修改：引入某類的一個子類，對要修改的一些行為（即虛函數或虛方法）進行重載，也確實是對它們重新定義。由于不再在原來的程序模塊中引入修改，因此完全解決了軟件的可修改性，從而也完全解決了軟件的可維護性。OO技術還提高了軟件的可靠性和健壯性。開發環境在項目實施過程中，項目開發環境建議：個人開發電

38、腦開發人員在各自的電腦上進行程序開發。開發服務器開發人員在開發服務器上進行單元測試，系統分析師在上面對代碼進行走查。建構治理服務器該服務器用來治理當前版本及版本發行。測試服務器該服務器用來進行系統的集成測試和交付測試。要緊開發工具使用Eclipse作為要緊開發工具。Eclipse是聞名的跨平臺的自由集成開發環境（IDE）。最初要緊用來Java語言開發，然而目前亦有人通過插件使其作為其他計算機語言比如C+和Python的開發工具。Eclipse的本身只是一個框架平臺，然而眾多插件的支持使得Eclipse擁有其他功能相對固定的IDE軟件專門難具有的靈活性。許多軟件開發商以Eclipse為框架開發自

39、己的IDE。Eclipse 最初由OTI和IBM兩家公司的IDE產品開發組創建，起始于1999年4月。IBM提供了最初的Eclipse代碼基礎，包括Platform、JDT 和PDE。目前由IBM牽頭，圍繞著Eclipse項目差不多進展成為了一個龐大的Eclipse聯盟，有150多家軟件公司參與到Eclipse項目中，其中包括Borland、Rational Software、Red Hat及Sybase等。Eclipse是一個開發源碼項目，它事實上是Visual Age for Java的替代品，其界面跟先前的Visual Age for Java差不多，但由于其開放源碼，任何人都能夠免費得

40、到，并能夠在此基礎上開發各自的插件，因此越來越受人們關注。近期還有包括Oracle在內的許多大公司也紛紛加入了該項目，并宣稱Eclipse今后能成為可進行任何語言開發的IDE集大成者，使用者只需下載各種語言的插件即可。Eclipse是一個開放源代碼的軟件開發項目，專注于為高度集成的工具開發提供一個全功能的、具有商業品質的工業平臺。它要緊由Eclipse項目、Eclipse工具項目和Eclipse技術項目三個項目組成，具體包括四個部分組成Eclipse Platform、JDT、CDT和PDE。JDT支持Java開發、CDT支持C開發、PDE用來支持插件開發，Eclipse Platform則是

41、一個開放的可擴展IDE，提供了一個通用的開發平臺。它提供建筑塊和構造并運行集成軟件開發工具的基礎。Eclipse Platform同意工具建筑者獨立開發與他人工具無縫集成的工具從而無須分辨一個工具功能在哪里結束，而另一個工具功能在哪里開始。Eclipse的插件機制是輕型軟件組件化架構。在客戶機平臺上，Eclipse使用插件來提供所有的附加功能，例如支持Java以外的其他語 言。 已有的分離的插件差不多能夠支持C/C+（CDT）、Perl、Ruby，Python、telnet和數據庫開發。插件架構能夠支持將任意的擴展加入到 現有環境中，例如配置治理，而決不僅僅限于支持各種編程語言。Eclipse

42、的設計思想是：一切皆插件。Eclipse核心專門小，其它所有功能都以插件的形式附加于Eclipse核心之上。Eclipse差不多內核包括：圖形API (SWT/Jface)， Java開發環境插件(JDT )，插件開發環境(PDE)等。驗證測試治理驗證與確認流程驗證的目的，是確保工作產品符合其指定的需求。確認的目的，是展示置于預期環境中的產品或產品組件，可滿足其預期的使用需求。驗證和確認流程如下：系統測試方案因應本系統質量及安全性要求，當系統開發完成之后需要從功能整合、系統效能、系統接口、數據轉換、安全等方面進行測試。系統測試方案規劃如下：具體測試的執行方式如下表所述：測試類不測試標的測試者測

43、試環境講明UT(單元測試)PG開發完成的組件、功能或程序（包括數據轉換及系統接口模塊）程序開發者(PG)開發環境功能驗收后方可進行功能整合測試功能整合測試已驗收的功能整合成模塊（包括數據轉換及系統接口模塊）；模塊整合成子系統測試團隊功能整合測試環境功能整合測試由測試團隊制訂測試打算來執行，建議能夠采納持續集成的方式執行效能壓力測試通過功能整合的模塊或子系統測試團隊模擬生產環境效能測試建議直接在為生產而預備的軟硬件環境下執行交付測試通過功能整合的模塊或子系統測試團隊交付測試環境數據轉換和系統接口測試需與交付測試相結合，即待測系統的數據來源是通過數據轉換及系統接口而來，同時能與外部系統正常介接數據

44、轉換測試通過功能整合的模塊或子系統測試團隊交付測試環境系統接口測試通過功能整合的模塊或子系統測試團隊交付測試環境HA測試系統軟硬件環境與應用的搭配客戶IT人員模擬生產環境選擇某批交付的產品進行HA測試用戶系統整合測試(SIT)通過交付測試的分批交付產品(LotX)客戶IT人員用戶SIT環境分批交付的驗收動作用戶系統驗收測試(UAT)通過用戶SIT的分批交付產品(LotX)客戶用戶代表用戶UAT環境用戶完整系統驗收測試(UAT)針關于已通過分批驗收的完整產品客戶用戶代表用戶UAT環境最終系統的驗收驗證與確認標準下面是軟件設計開發過程中分析、評審的重要量化指標：活動產品度量單位平均值密度缺陷率合格

45、率RD ReviewReq. Doc.Req. Doc.由DFPV提供AD ReviewAD Doc.2.00-HD ReviewHD Doc.2.00-DD ReviewDD Doc.UC-7.00-UTCODEKLOC758.00-WTVaKLOC-5.00-ITVbKLOC354.50-RTVcKLOC61.500.45簡寫講明RD需求開發AD 架構設計HD概要設計DD詳細設計UT/CODE單元測試（源代碼）WT/Va程序走查（版本(a)）IT/Vb整合測試（版本(b)）RT/Vc交付測試（版本(c)）UC用例KLOC千行代碼實施治理項目開發實施打算為了確保項目目標達成和項目順利實施，項

46、目規劃和項目的監控是至關重要的環節，因而我公司在項目治理過程中，對項目實施進行如下維度的規劃：項目基準打算：依據項目治理的九大構面對項目進行整體規劃，其內容包括項目目標及范圍定義、項目成本和預算、項目整體時程規劃和里程碑打算、項目質量打算、項目組織和溝通打算、項目資源規劃、項目環境及建構治理打算、外包及采購打算、項目風險打算，項目基準打算被視為項目組對公司和客戶的承諾，同時作為項目執行績效的比較基準。時期詳細打算：依據基準打算的整體安排，項目不同時期均會制訂詳細的時程打算，通過WBS分解并落實到具體活動(Activity)，作為每個時期及每個團隊工作執行的指導，并作為進度檢查的重要依據。個人工

47、作打算：依據詳細打算安排的工作事項，會作為個人的工作包分配給具體的執行人，由執行人對工作進行細化，個人工作打算實質為個人對項目組的承諾。依據以上打算的內容，項目實施過程中，會有不同頻度和范圍的檢討：每日個人對工作包執行狀態進行回報。每周進行小組或項目組織的進度審查，同時關于進度偏差及項目執行過程中所遇到的問題進行討論和解決。每月項目審查會議，由項目組與項目相關干系人（如：公司治理者、客戶）依據項目基準打算進行檢查，對項目執行過程中的重大問題進行討論和解決。里程碑審查會議，針關于項目重大里程碑設定評審會議，決定項目Go/No Go的判定。溝通治理有效溝通是確保項目成功的重要保障，在項目治理過程中

48、通過項目會議和檢查以及問題溝通處理機制來保持溝通的通暢。項目檢討我公司每周五提供項目周報，報告一周來的工作進展情況。每周一進行一次項目會議，對上一周的工作進行討論和總結，雙方的項目經理均需出席。會議要緊內容如下：檢查項目執行情況跟蹤風險調整打算跟蹤行動跟蹤異常情況通告項目進展情況問題處理項目實施過程中會遇到不同類不的問題，我們一般將問題分為以下四類：項目問題(PPR, Project Problem Report)，指項目治理范籌中，阻礙項目進度、交付、質量、成本、溝通、人員治理和合約等方面的問題。項目問題在每周周會進行檢討，同時關于需要協調解決的問題需要由我公司和客戶項目經理一同組織專門的會

49、議協調相關的項目干系人(Stakeholder)參加會議進行討論并解決問題。變更請求(CRR,Change Request Report)，指與項目范圍及軟件產品需求基準(Baseline)相比較而產生的變更，有新需求（New Requirement）、需求變更(Changed Requirement)或需求取消（Canceled Requirement），從而阻礙到項目的進度、質量要求、交付的時刻或開發的成本等。項目的變更請求，既能夠由客戶直接提出，也能夠由我公司項目組識不出來后通知客戶，由客戶認定后再提出變更請求。同時當雙方關于變更請求的處理方案、人力及成本預估存在爭議，無法由雙方項目組達

50、成共識時，建議由CCB(Change Control Board)來協調討論，并對爭議做最后裁決。其中CCB的構成由雙方高層治理者、雙方項目經理以及相應的領域專家構成。軟件問題(SPR, Software Problem Report)，指軟件產品測試或驗證過程中所發覺的問題(Issue)。軟件問題(SPR)的處理能夠采納測試治理的工具來進行治理，但雙方一定均能訪問，并能夠更新相應的狀態和講明字段。軟件問題(SPR)的處理結果及進度，能夠列入到每周例會的檢討內容。Q&A(Question And Answer)，項目實施過程中需要進行澄清的疑問。項目實施過程中針關于不同方面的Q&A雙方應指定對

51、應的窗口，如技術問題、不同領域的需求功能問題等都有各自對應的窗口，如此會讓問題有統一的治理并提高解答的成效。關于問題的提出，先由我公司內部進行討論及解答，只有內部無法解答的問題才會提交客戶回復。風險治理項目風險是項目治理過程中潛在的問題。項目風險可能引起項目不能按時交付，或達不到預期的質量，或需要增加項目成本。風險治理是一種對項目風險進行識不、分析、應對的系統過程。它包括鼓舞對項目目標有正面阻礙的風險發生并加強其阻礙、減小對項目目標有負面阻礙的風險發生并減弱其阻礙。風險治理策略如下圖：風險治理規劃決定如何進行與規劃項目的風險治理活動。風險識不推斷哪些風險會阻礙項目，并做正式記錄。風險分析風險定

52、性分析：對風險及其條件進行定性分析，并依其對項目目標阻礙進行排序。風險定量分析：量度風險的概率與后果，可能其對項目目標造成的阻礙。風險應對規劃制訂為項目目標增加機會、減輕威脅的程序與技術。風險監測與追蹤在項目整個生命期間監測殘余風險、識不新風險，執行減輕風險打算，并對這些打算的有效性進行評估。風險識不與分析風險是由項目團隊成員（客戶方 或 農商行）進行識不和分析的。風險必須上升到項目級對待。按照危險程度，風險可分為不同等級，關于風險等級為6到9的危險風險必須制定詳細的解決打算。以下各表分不是風險嚴峻性、風險可能性、風險等級的分類講明。風險可能性可能性描述1 Weak此類事件發生幾率專門小。2

53、Average此類風險發生和不發生的可能性均等。3 Strong此類事件專門有可能發生。風險嚴峻性嚴峻性描述1 Weak此類風險不阻礙項目預期目標，如成本、進度、質量、技術內容。2 Average此類風險阻礙項目部分功能但不阻礙最終執行。3 Strong此類風險阻礙方案的執行。可能最終因起財務損失，甚至阻礙項目。風險等級風險處理流程質量治理質量治理，是指質量治理員（QA）通過對項目過程中的產品或服務進行有效的稽核，以確保項目的品質不出現問題。項目啟動時期，品質保證員將依照項目的基線打算和詳細開發打算制訂品質稽核打算，列出稽核點和稽核時刻。項目實施過程中，品質保證員將按照打算進行品質稽核工作，對

54、發覺的問題產生不合格報告，并對不合格報告進行追蹤，以監督項目組對不合格問題進行改進。每周品質保證員將提交品質稽核周報，在項目周會上進行檢討。項目結案時期，品質保證員將對整個項目實施過程中的品質情況進行分析和總結，提交項目品質分析報告。品質保證流程圖：建構治理建構治理流程領域使用建構識不、建構操縱、建構狀態紀錄，以及建構稽核，來建立與維護工作產品的完整性。并經由建立與維護工作產品的完整性，來支持所有的流程領域。開發環境在項目實施過程中，項目開發環境建議：個人開發電腦開發人員在各自的電腦上進行程序開發。開發服務器開發人員在開發服務器上進行單元測試，系統分析師在上面對代碼進行走查。建構治理服務器該服務器用來治理當前版本及版本發行。測試服務器該服務器用來進行系統的集成測試和交付測試。建構治理對象納入建構治理的工作產品包括：交付客戶的產品、指定的內部工作產品、采購的產品、工具，以及用來產生與講明這些工作產品的其它項目。建構治理工作內容建構治理工作內容包括：識不建構項、規劃基線、創建建構