軟件項目標書范本

1、Actuate Confidential 5/4/2008中國外匯交易中心數(shù)據(jù)倉庫一期項目建議第二冊 技術部分安訊軟件（上海）有限公司2008年5月4日目錄1項目目標12技術解決方案22.1系統(tǒng)總體架構22.1.1邏輯架構22.1.1.1功能層面（上側面）22.1.1.2非功能層面（右側面）32.1.2設計層面32.1.2.1ETL數(shù)據(jù)抽取32.1.2.2報表設計32.1.2.3報表展現(xiàn)32.1.2.4報表應用32.1.3物理架構32.1.4數(shù)據(jù)架構52.2系統(tǒng)技術實現(xiàn)方案62.2.1總體技術實現(xiàn)方案62.2.2高效的ETL處理72.2.2.1ETL總體處理流程72.2.2.2數(shù)據(jù)倉庫模型設計

2、92.2.3數(shù)據(jù)質量管理102.2.3.1數(shù)據(jù)倉庫對數(shù)據(jù)質量的要求102.2.3.2數(shù)據(jù)質量改進目標102.2.3.3數(shù)據(jù)質量改進方法102.2.4報表平臺設計112.2.4.1靈活的報表查詢122.2.4.2先進的報表開發(fā)模式122.2.4.3高效的報表消費122.2.4.4老系統(tǒng)統(tǒng)計報表移植122.2.5認證管理132.2.6系統(tǒng)可靠性及可擴展性132.2.7非功能性設計142.2.7.1性能需求142.2.7.2 災備設計152.2.7.3可獲性設計172.2.7.4 易用性設計172.2.7.5 安全性設計183項目管理193.1溝通管理193.1.1項目會議制度193.1.1.1定期

3、會議203.1.1.2不定期會議203.1.2項目狀態(tài)周報制度213.1.3溝通手段213.2配置管理223.2.1配置管理原則223.2.2配置庫管理223.3變更管理223.3.1發(fā)起變更223.3.2評估變更233.3.3審批變更233.3.4執(zhí)行變更233.3.5變更執(zhí)行評估233.4質量管理243.4.1質量規(guī)劃243.4.2質量保證253.4.3質量檢查264工期進度265附錄27第二冊 技術部分1 項目目標CFETS希望通過數(shù)據(jù)倉庫系統(tǒng)的建設，可以有效地整合各市場業(yè)務數(shù)據(jù)，統(tǒng)一對信息進行利用和管理，對外提供統(tǒng)一的數(shù)據(jù)視圖和綜合決策分析支撐環(huán)境，為CFETS各部門所需的報表應用、統(tǒng)

4、計分析及信息挖掘提供基礎支持平臺。具體建設目標如下：（1）技術目標 建立數(shù)據(jù)倉庫基礎架構 建立自動數(shù)據(jù)抽取轉換加載（ETL）機制 建立多維分析和數(shù)據(jù)查詢工具和界面已經(jīng)分析報表生成和展示框架（2）業(yè)務目標 實現(xiàn)一期經(jīng)營分析的多維分析、查詢和報表，提供CFETS各部門所需報表 提供下游系統(tǒng)所需要的統(tǒng)計數(shù)據(jù) 提供中心內部用戶以Ad-Hoc方式查詢所需數(shù)據(jù) 將業(yè)務系統(tǒng)的歷史和增量數(shù)據(jù)加載進入數(shù)據(jù)倉庫，并轉換為數(shù)據(jù)倉庫的存儲格式 實現(xiàn)用戶訪問的門戶界面并建立相應的訪問安全和權限機制 進行老系統(tǒng)統(tǒng)計報表的移植工作，保證數(shù)據(jù)倉庫系統(tǒng)中的報表統(tǒng)計結果與原報表統(tǒng)計結果的一致性基于上述需求，安訊軟件（上海）有限公

5、司提出如下技術解決方案來實現(xiàn)本項目的技術目標和業(yè)務目標。2 技術解決方案2.1 系統(tǒng)總體架構2.1.1 邏輯架構總體邏輯架構如下：2.1.1.1 功能層面（上側面）根據(jù)CFETS對應的功能需求，對應的功能層面上需要建立如下功能： 數(shù)據(jù)的ETL 數(shù)據(jù)存儲 固定統(tǒng)計報表 統(tǒng)一用戶界面及Portal認證管理2.1.1.2 非功能層面（右側面） 易用性 響應性 可靠性 擴展性 安全性2.1.2 設計層面2.1.2.1 ETL數(shù)據(jù)抽取通過成熟的ETL工具，實現(xiàn)從不同的數(shù)據(jù)源中抽取出所需要的信息，同時通過數(shù)據(jù)的加工和格式化，對外提供給其他系統(tǒng)使用。2.1.2.2 報表設計當形成好統(tǒng)一的數(shù)據(jù)倉庫后，基于該倉

6、庫模型，可進行對應的報表設計和管理，技術人員設計好基本的報表后，可提供給業(yè)務人員使用。2.1.2.3 報表展現(xiàn)技術人員設計好報表模板后，通過發(fā)布到對應的服務器據(jù)，實現(xiàn)對報表的展現(xiàn)。2.1.2.4 報表應用業(yè)務人員通過終端界面，可以使用由開發(fā)人員開發(fā)和設計的報表，同時，業(yè)務人員也能同報表進行交互，檢索出自己需要的數(shù)據(jù)。2.1.3 物理架構對于本，外幣不同的數(shù)據(jù)源，以及不同的物理子系統(tǒng)，基本的物理架構如下：物理架構說明：A. 本外幣數(shù)據(jù)庫向倉庫提供對應的數(shù)據(jù)B. 倉庫為對應的報表服務器提供統(tǒng)一的視圖。C. 權限報表服務器部署到同一機器上。2.1.4 數(shù)據(jù)架構數(shù)據(jù)流說明：A. 首先從本外幣或者其他系

7、統(tǒng)獲得對應的數(shù)據(jù).B. 經(jīng)過ETL對數(shù)據(jù)進行加工，清洗和標準化。C. 將已經(jīng)標準化和模型化的數(shù)據(jù)進入到數(shù)據(jù)倉庫，或者提供需要的數(shù)據(jù)文件。D. 數(shù)據(jù)倉庫對外暴露數(shù)據(jù)模型和數(shù)據(jù)視圖以及sql接口。E. 數(shù)據(jù)倉庫為報表管理系統(tǒng)和下游系統(tǒng)提供所需要的數(shù)據(jù)F. 報表管理系統(tǒng)展現(xiàn)對應數(shù)據(jù)的報表。2.2 系統(tǒng)技術實現(xiàn)方案2.2.1 總體技術實現(xiàn)方案充分考慮到CFETS系統(tǒng)存在在本外幣等多種數(shù)據(jù)源，且數(shù)據(jù)源分散，多分散子系統(tǒng)的情況，同時各個子系統(tǒng)中存在統(tǒng)計口徑不一致，影響統(tǒng)一的決策和各個部門信息的一致性。在使用的過程中，會員信息維護復雜，且各個系統(tǒng)各自維護一套對應的會員信息，導致會員維護工作量加大。數(shù)據(jù)倉庫一

8、期需求大致可以分成數(shù)據(jù)庫架構的建立、ETL機制的建立、以及報表分析架構的建立和報表實施。系統(tǒng)可以分成數(shù)據(jù)倉庫和報表系統(tǒng)兩大部分。以下是我們建議的系統(tǒng)架構概念圖：系統(tǒng)包含一個雙機組成的數(shù)據(jù)倉庫，和一個雙機組成的報表服務平臺。數(shù)據(jù)倉庫和報表服務器分別帶有自己的外存磁盤陣列。架構中的每個功能節(jié)點設計都含冗余度，保證系統(tǒng)不存在單一失敗點，滿足提供7x24不間斷服務的要求。在系統(tǒng)架構不變的前提下，系統(tǒng)的每部分可以用不同的技術實現(xiàn)。比如，數(shù)據(jù)庫管理系統(tǒng)可以使用Oracle的技術，也可以使用IBM的技術。報表技術建議使用Actuate 9。使用我們建議的應用軟件，這樣的系統(tǒng)架構會有很強的可擴展性，用戶可以通

9、過增加硬件的方式擴容，以支持越來越多的用戶和應用?？傮w方案通過以下步驟實現(xiàn)數(shù)據(jù)到可用信息的轉換：1. 通過ETL手段對不同的數(shù)據(jù)源數(shù)據(jù)進行抽取，轉換，清洗，數(shù)據(jù)格式化。2. 通過ETL轉化后的數(shù)據(jù)統(tǒng)一進入數(shù)據(jù)倉庫，形成統(tǒng)一的數(shù)據(jù)視圖。3. 進入數(shù)據(jù)倉庫的數(shù)據(jù)模型可以為報表平臺提供對應的數(shù)據(jù)來源。4. 通過認證的用戶可以登陸報表平臺消費和設計對應的報表。2.2.2 高效的ETL處理2.2.2.1 ETL總體處理流程ETL處理流程：1. 從本幣數(shù)據(jù)源或其他數(shù)據(jù)源中抽取需要的數(shù)據(jù)。2. ETL對抽取到的數(shù)據(jù)進行必要的增量處理，生成一天的增量數(shù)據(jù)。3. ETL對增量數(shù)據(jù)進行技術性檢核、標準化、轉換。4

10、. 產(chǎn)生LDM落地數(shù)據(jù)文件。5. 落地數(shù)據(jù)文件下發(fā)到下游系統(tǒng)，同時進行數(shù)據(jù)入庫。6. 整個ETL處理過程進行異常處理及監(jiān)控。ETL實施我們建議采用成熟的ETL工具，所選ETL工具需要滿足如下基本要求：（1）技術架構1)支持所有的主流平臺2)模塊化的架構設計，可按需進行模塊添加和擴展3)具有錯誤恢復邏輯的功能4)支持并行處理（2） 核心功能1)支持本地數(shù)據(jù)訪問模式2)支持星型模式3)支持打包應用（例如SAP）4)支持基本處理（例如SQL）5)具有數(shù)據(jù)自動轉換和清洗功能6)支持實時ETL和按需ETL7)具有自動錯誤預警功能（3） 開發(fā)環(huán)境1)圖形化界面2)支持命令行3)便于調試和維護4)具有代碼版

11、本控制功能（4） ETL管理1)支持集中管理2)自動產(chǎn)生每日ETL運行報表3)具有ETL自動和手工調度功能我們相信商業(yè)ETL工具中INFORMATICA會是一個很好的選擇，開源ETL產(chǎn)品Kettle則是INFORMATICA之外一個很好的備選。2.2.2.2 數(shù)據(jù)倉庫模型設計數(shù)據(jù)建模 建模過程：（以常用會計報表為例）1. 用戶需要查看基于時間、機構和科目的報表。2. 建立以數(shù)據(jù)事實表為中心，需要時間、機構和度量作為其維度。3. 建立好如上的星型模型后，可發(fā)現(xiàn)模型具有如下優(yōu)點。4. 靈活的數(shù)據(jù)查詢，可基于時間查詢對應的日報，月報和季報。5. 效率最優(yōu)化，需要查詢機構信息，則通過機構和事實表關聯(lián)即

12、可完成。2.2.3 數(shù)據(jù)質量管理2.2.3.1 數(shù)據(jù)倉庫對數(shù)據(jù)質量的要求數(shù)據(jù)倉庫對數(shù)據(jù)質量的要求總體上歸納為：數(shù)據(jù)完整性，包括數(shù)據(jù)源是否完整、數(shù)據(jù)取值是否完整、維度取值是否完整等。數(shù)據(jù)準確性，包括數(shù)據(jù)源是否準確、編碼映射關系是否準確、處理邏輯是否準確等。數(shù)據(jù)核對準確的判斷是要么結果一致，要么不一致但原因是可解釋的。數(shù)據(jù)一致性，包括源系統(tǒng)之間同一數(shù)據(jù)是否一致，源數(shù)據(jù)與抽取的數(shù)據(jù)是否一致，數(shù)據(jù)倉庫內部各處理環(huán)節(jié)數(shù)據(jù)是否一致等。數(shù)據(jù)邏輯合理性，主要從業(yè)務邏輯的角度判斷數(shù)據(jù)是否正確，如帳目類型的金額、時長、次數(shù)的邏輯關系是否滿足等。數(shù)據(jù)時效性，包括數(shù)據(jù)處理（獲取、整理、加載等）的及時性，數(shù)據(jù)異常檢測的

13、及時性，數(shù)據(jù)處理回退的及時性等。數(shù)據(jù)倉庫服務于經(jīng)營決策，經(jīng)營決策依據(jù)的數(shù)據(jù)應該是全面的、真實可靠的、有意義的。數(shù)據(jù)時效性如果得不到保證，就可能延誤了市場人員的分析，失去商機。從數(shù)據(jù)倉庫的建設過程來看，它本身修復數(shù)據(jù)以提高數(shù)據(jù)質量的能力并不是很強，但是它能發(fā)現(xiàn)生產(chǎn)系統(tǒng)存在的一些數(shù)據(jù)質量問題從而提醒用戶哪些數(shù)據(jù)有質量問題，將數(shù)據(jù)問題反饋到業(yè)務支撐系統(tǒng)中，由后者做數(shù)據(jù)修正。2.2.3.2 數(shù)據(jù)質量改進目標數(shù)據(jù)質量改進的目標是清理、標準化、提高和匹配現(xiàn)有數(shù)據(jù)。通過數(shù)據(jù)整合，建立完整的、準確的、一致的統(tǒng)一客戶視圖，完善共享信息數(shù)據(jù)，并使共享信息數(shù)據(jù)服務于經(jīng)營分析，為生產(chǎn)系統(tǒng)的改進提供標準。 建立數(shù)據(jù)整合

14、流程，實現(xiàn)流程定義、流程配置和流程管控。 建立數(shù)據(jù)整合的規(guī)章制度，落實數(shù)據(jù)質量的分級負責。建立起數(shù)據(jù)整合隊伍，使數(shù)據(jù)質量能夠得以持續(xù)改進。2.2.3.3 數(shù)據(jù)質量改進方法數(shù)據(jù)質量控制要從技術、流程和管理三個方面進行。從技術層面上，生產(chǎn)系統(tǒng)存在的噪音數(shù)據(jù)、遺漏數(shù)據(jù)和不一致性數(shù)據(jù)，需要進行數(shù)據(jù)清洗；同時需要對源數(shù)據(jù)做稽核，如總量稽核和分量稽核。在流程層面上，對于源數(shù)據(jù)的抽取要遵從一定的業(yè)務規(guī)則，數(shù)據(jù)的抽取和轉換需要很多步驟來完成，這就需要將過程流程化，并且流程可通過配置來實現(xiàn)。在管理層面上，要求生產(chǎn)系統(tǒng)報送數(shù)據(jù)，按照“誰提供數(shù)據(jù)，誰負責”的原則由生產(chǎn)系統(tǒng)保證源數(shù)據(jù)的完整性、準確性、一致性、時效性。

15、下面是我們在技術層面采取的具體做法。在ETL架構設計中我們會包括數(shù)據(jù)質量設計，將數(shù)據(jù)質量檢查腳本加入到ETL流程中，分為技術檢查和業(yè)務規(guī)則檢查。錯誤分嚴重程度，如主鍵重復的就停止ETL流程，等待解決，但低級別的錯誤不會阻塞ETL過程。在這個過程中，所有的錯誤都會進行記錄，最終生成數(shù)據(jù)質量檢查報告。但需要明確的是，很多情況下，許多數(shù)據(jù)問題在ETL之前都無法知道，只能通過ETL之后的數(shù)據(jù)核對才能發(fā)現(xiàn)，然后逐漸積累，加到ETL的規(guī)則控制中去。2.2.4 報表平臺設計建立報表查詢門戶，提供各類信息報表的查詢，統(tǒng)一查詢渠道，統(tǒng)一數(shù)據(jù)口徑，統(tǒng)一用戶管理。多個管理信息系統(tǒng)在報表平臺上表現(xiàn)為一個個獨立的邏輯子

16、系統(tǒng)。通過報表平臺，技術人員可以通過靈活配置邏輯系統(tǒng)集成不同BI工具產(chǎn)生的異構報表資源，業(yè)務人員可以進行不同報表資源的集中管理和發(fā)布，最終用戶可以通過一致的展示環(huán)境獲取報表信息。具體設計如下：2.2.4.1 靈活的報表查詢 在報表的查詢過程中，可以通過瀏覽器直接瀏覽報表，同時，用戶也可以通過簡單的操作，對報表進行重新訂制，為了更好的提高實用性，用戶可通過瀏覽器同報表服務器進行交互，查看到需要的報表。2.2.4.2 先進的報表開發(fā)模式在報表的開發(fā)中，我們將采用最先進的協(xié)同開發(fā)模式，開發(fā)人員定制業(yè)務邏輯，業(yè)務人員根據(jù)自己需要通過簡單的拖動則可形成自己需要的報表。2.2.4.3 高效的報表消費在使用

17、的過程中，業(yè)務人員根本不用關心對應的后臺業(yè)務邏輯，以及數(shù)據(jù)信息來源等信息，其只要根據(jù)自己的業(yè)務需要，通過簡單的拖拽即可完成對報表的定制，獲取到自己需要的信息。2.2.4.4 老系統(tǒng)統(tǒng)計報表移植對于老系統(tǒng)的統(tǒng)計報表，我們將采取重寫的方式移植到統(tǒng)一的報表平臺上面。重寫后的統(tǒng)計報表基于新建的數(shù)據(jù)倉庫，這樣就統(tǒng)一了現(xiàn)存的多個統(tǒng)計系統(tǒng)，統(tǒng)一了統(tǒng)計口徑，解決了統(tǒng)計口徑不一致所造成的各個部門信息的不一致，并消除這種不一致對管理決策帶來的負面影響。老系統(tǒng)報表遷移的一個難點是如何保證數(shù)據(jù)倉庫系統(tǒng)中的報表統(tǒng)計結果與原報表統(tǒng)計結果的一致性，對此要具體問題具體分析。新報表的統(tǒng)計結果與原報表的統(tǒng)計結果不一致只可能是兩種

18、情況：新報表的統(tǒng)計方式是錯誤的，造成新老報表統(tǒng)計結果不一致；新老報表的統(tǒng)計口徑不一致，造成統(tǒng)計結果不一致。如果是前一種情況，采用正確的統(tǒng)計方式就能修正錯誤。如果是后一種情況，則需要根據(jù)業(yè)務的需要選擇統(tǒng)計口徑，使新報表能夠達到業(yè)務人員的預期。我們將會采用嚴格的測試手段來保證新報表與老報表統(tǒng)計結果的一致性。測試的目的，是驗證對于相同的輸入，新老報表得到的輸出結果完全一致。實際測試中，我們將采用等價類劃分以及邊值分析法來設計測試用例，產(chǎn)生有限的測試用例來覆蓋足夠多的“任何情況”。對有差異的報表，我們會作進一步的數(shù)據(jù)集對比，以確定問題的根源到底是在數(shù)據(jù)，還是報表邏輯。2.2.5 認證管理 在對用戶信息

19、的管理中，提供以角色和用戶為安全模型的統(tǒng)一認證機制，只有具有對應角色的用戶才能訪問對應的報表。2.2.6 系統(tǒng)可靠性及可擴展性系統(tǒng)的可靠性及可擴展性對企業(yè)級應用來說是非常重要的。我們的設計充分考慮了這兩個因素。針對可靠性，我們的設計是在系統(tǒng)包含一個雙機組成的數(shù)據(jù)倉庫，和一個雙機組成的報表服務平臺。數(shù)據(jù)倉庫和報表服務器分別帶有自己的外存磁盤陣列。架構中的每個功能節(jié)點設計都含冗余度，保證系統(tǒng)不存在單一失敗點，滿足提供7x24不間斷服務的要求。采用的這樣系統(tǒng)架構，主機系統(tǒng)的維護、系統(tǒng)擴容、升級、系統(tǒng)性能統(tǒng)計、分析、優(yōu)化以及部件更換就能夠在不影響應用系統(tǒng)功能的前提下完成。而所有關鍵部件能夠保證在不停頓

20、數(shù)據(jù)共享服務的前提下提供熱插拔能力。對于可擴展性，使用我們建議的報表服務平臺安訊iServer，系統(tǒng)架構會有很強的可擴展性，用戶可以通過增加硬件的方式擴容，以支持越來越多的用戶和應用。安訊iServer可以運行在由多臺服務器組成的集群上，利用任務控制與自動負載平衡技術，將任務平均分配到各臺服務器上。安訊iServer具備出色的可擴展性，用戶可以簡單的向集群中添加更多的服務器來滿足更高的報表需求，而系統(tǒng)的性能隨著服務器數(shù)量的增多呈線性增長，這方面的具體數(shù)據(jù)請參考附錄D “安訊9系統(tǒng)性能白皮書”。在集群系統(tǒng)中，安訊iServer可以通過不同的故障轉移模(Failover)式來保障iServer各項

21、服務的可用性。對系統(tǒng)可擴展性的考慮能充分保證用戶不在初期購買超出業(yè)務量需求的處理能力。隨著用戶業(yè)務量的增長，主機系統(tǒng)能隨時動態(tài)擴展處理能力，且系統(tǒng)性能是線性增長的，任何業(yè)務量的增長需要都能夠通過對主機的線性擴展得到滿足。2.2.7 非功能性設計2.2.7.1 性能需求2.2.7.1.1 容量設計根據(jù)1994-2007年的所有交易數(shù)據(jù)總容量為10G byte，大概每年的數(shù)據(jù)容量在800M左右，從容量和可擴展性和災備等多方面綜合考慮，建議每年的數(shù)據(jù)量分配在2.5G左右。2.2.7.1.2 響應設計高的響應能給用戶帶來效率上的提升 ，加快了工作效率，減少了等待時間，同時加快了系統(tǒng)的處理效率，我們將通

22、過以下幾方面手段來保證用戶得到高質量的響應：1. 優(yōu)化模型設計，好的模型設計能夠減少冗余數(shù)據(jù)量的加載和檢索，以及表間關聯(lián)檢索，能大大提高系統(tǒng)數(shù)據(jù)的響應時間。2. 有效利用數(shù)據(jù)庫的緩存功能，對于經(jīng)常訪問的數(shù)據(jù)，可將數(shù)據(jù)緩存于數(shù)據(jù)庫中，減少IO，3. 利用集群功能，合理分配負載，充分利用各主機的CPU, 內存等硬件資源。4. 優(yōu)化報表設計，減少報表生成所需要的系統(tǒng)資源。5. 充分利用報表系統(tǒng)的緩存功能，把報表生成任務安排到非高峰時段。6. 充分利用報表系統(tǒng)的對查詢的緩存功能，減少對數(shù)據(jù)源的實時訪問。2.2.7.2 災備設計2.2.7.2.1 災備級別 高: 內部系統(tǒng)核心數(shù)據(jù)，包括所有連機和脫機數(shù)據(jù)

23、，需要高級別的備份。 中：系統(tǒng)需要的資料數(shù)據(jù)。 低：與系統(tǒng)關系不大，偶爾系統(tǒng)需要使用到的數(shù)據(jù)。由此可見，對于高，中級別的數(shù)據(jù)，需要進行對應的備份。2.2.7.2.2 備份策略為了保障核心數(shù)據(jù)和重要數(shù)據(jù)的完整性和一致性，我們將提供對應的磁盤備份、聯(lián)機備份和遠程備份功能：磁盤備份：通過鏡像 (mirrored) 磁盤矩陣, 對每一個寫到磁盤的字節(jié)，作實時的鏡像備份，減少磁盤機出錯的幾率。磁盤備份一旦設定，由設備實現(xiàn)，無需人工干預。聯(lián)機備份：提供24*365天的備份機制，用戶可以基于調度來運行備份，可以基于系統(tǒng)運行的熱備份。我們設計方案中使用的Oracle 10g 或IBM DB 2 數(shù)據(jù)庫，都支持

24、熱備份；Actuate 9 的報表服務器 iServer , 也支持聯(lián)機熱備份。 數(shù)據(jù)倉庫的數(shù)據(jù)和報表服務器的報表，可以每天進行一次熱備份。遠程備份：提供對付災害性的系統(tǒng)失敗的有效方式。遠程備份把數(shù)據(jù)存放到地理上的遠方，以應對主機可能遇到當?shù)貫暮π缘膿p毀。我們建議把每天的熱備份數(shù)據(jù)，拷貝到遠端備份存儲服務器。以上的備份策略，保證在不影響系統(tǒng)服務的條件下，在本地和遠程，都保留一份前一天的備份數(shù)據(jù)，包括數(shù)據(jù)倉庫和報表服務器的數(shù)據(jù)。當?shù)貍浞萁ㄗh保留30天；遠程備份建議保留7天。備份可以保存在磁帶庫、或光盤庫。本地備份耗時目標是2小時；遠程備份耗時目標是12小時。2.2.7.2.3 恢復策略常規(guī)的數(shù)據(jù)

25、恢復流程設計如下：1) 重啟系統(tǒng)的所有服務器和存儲設備2) 如必要，恢復系統(tǒng)3) 從本地備份選取前一天的備份，或最近的備份；如果本地備份丟失，取遠程備份4) 恢復數(shù)據(jù)倉庫和報表系統(tǒng)數(shù)據(jù)5) 恢復系統(tǒng)服務常規(guī)數(shù)據(jù)恢復一般是在文件系統(tǒng)失?。òù疟P設備失?。е聰?shù)據(jù)無法使用的情形下必須激活的程序。常規(guī)數(shù)據(jù)恢復保證系統(tǒng)回復到前一天的狀態(tài)，但也意味著當天數(shù)據(jù)的丟失。一般系統(tǒng)出錯的恢復，其實不一定需要用到備份，我們建議應該避免使用常規(guī)數(shù)據(jù)恢復，盡量考慮用其他辦法把系統(tǒng)回復到最近的可用狀態(tài)。以下我們以Oracle數(shù)據(jù)庫為例，說明一下可以考慮的恢復措施。數(shù)據(jù)庫的恢復過程分兩步進行，首先將把存放在重做日志文件

26、中的所有重做運用到數(shù)據(jù)文件，之后對重做中所有未提交的事務進行回滾。數(shù)據(jù)庫的恢復只能在發(fā)生故障之前的數(shù)據(jù)文件上運用重做，將其恢復到故障時刻，而不能將數(shù)據(jù)文件反向回滾到之前的某一個時刻。數(shù)據(jù)庫的異常、錯誤可以分為以下幾類： SQL語句失敗 線程失敗 實例失敗 用戶操作失敗 存儲設備失敗 如果發(fā)生前三種失敗，不需要人為干涉，系統(tǒng)會自動進行恢復。對于用戶操作型的失?。ㄈ缯`刪除數(shù)據(jù)），系統(tǒng)采取的補救措施主要有導入最新的邏輯備份或進行到某一時間點的不完全恢復。數(shù)據(jù)庫引入了基于表空間的時間點恢復(TSPITR)，可以單獨將包含錯誤操作的表空間恢復到指定時間，而不必對整個數(shù)據(jù)庫進行不完全恢復。當錯誤操作發(fā)現(xiàn)比

27、較及時而且數(shù)據(jù)量不大的情況下也可以考慮使用logminer生成反向SQL。 針對存儲設備的失敗的情況比較復雜，存儲設備的失敗必然會使放置在其上的文件變?yōu)椴豢捎?，我們先將?shù)據(jù)庫所涉及到的文件進行一個劃分，主要可分為： 數(shù)據(jù)庫的系統(tǒng)文件，指數(shù)據(jù)庫的運行文件，各種應用程序 數(shù)據(jù)庫控制文件 數(shù)據(jù)庫聯(lián)機重做日志文件 數(shù)據(jù)文件 歸檔日志文件 避免第一種文件失敗主要依賴系統(tǒng)管理員進行操作系統(tǒng)級的備份，當發(fā)生事故后只能依靠操作系統(tǒng)備份將其恢復。 控制文件中記錄著整個數(shù)據(jù)庫的結構、每個數(shù)據(jù)文件的狀況、系統(tǒng)SCN、檢查點計數(shù)器等重要信息，在創(chuàng)建數(shù)據(jù)庫時會讓用戶指定三個位置來存放控制文件，他們之間互為鏡像，當其中任

28、何一個發(fā)生故障，只需將其從ini文件中注釋掉故障數(shù)據(jù)文件就可重新將數(shù)據(jù)啟動。當所有控制全部失效時，可以在Nomount模式下執(zhí)行create controlfile來重新生成控制文件，但必須提供redo log，data file，文件名和地址以及MAXLOGFILES，MAXDATAFILES，MAXINSTANCES等信息。如果失敗之前運行過alter database backup controlfile to trace或alter database backup controlfile to xxx對控制文件作備份，恢復時可使用生成的腳本來重建或用備份文件覆蓋，如果使用了舊的控制文件

29、在恢復時要使用recover xxx using backup controlfile選項來進行恢復，并使用resetlogs選項來打開數(shù)據(jù)庫。2.2.7.3 可獲性設計按照我們在2.2.1中建議的系統(tǒng)架構，系統(tǒng)包含一個雙機組成的數(shù)據(jù)倉庫，和一個雙機組成的報表服務平臺。數(shù)據(jù)倉庫和報表服務器分別帶有自己的外存磁盤陣列。架構中的每個功能節(jié)點設計都含冗余度，保證系統(tǒng)不存在單一失敗點。 此外，高可獲性來自于我們建議的軟件系統(tǒng)，無論是Oracle, IBM DB2, 或Actuate 9, 都支持失敗轉移等高級集群功能，滿足提供7x24不間斷服務的要求，能夠保證滿足任何時候系統(tǒng)的可獲性需求。2.2.7.

30、4 易用性設計在軟件的易用性方面，我們將充分考慮用戶的體驗性，簡單性，高效率性為客戶定制一套更適合客戶需要的的系統(tǒng)，根據(jù)需要，我們將基于以下方面進行設計： 使用大眾化WEB瀏覽器如IE、Firefox作為客戶端的瀏覽工具。 用戶界面友好、同時易操作。 界面操作符合瀏覽習慣。 界面風格，術語統(tǒng)一。 靈活的頁面布局，支持標簽頁。 合理的組織操作菜單 查詢等出現(xiàn)錯誤時提供友好的提示。 提供友好的聯(lián)機幫助界面。2.2.7.5 安全性設計2.2.7.5.1 身份認證系統(tǒng)提供身份認證功能。使用系統(tǒng)的用戶必須先要經(jīng)過申請審批管理流程，通過有關部門管理人員的合法性審批，系統(tǒng)管理員在系統(tǒng)管理模塊中設置用戶名、操

31、作權限和初始密碼，并告知用戶后，用戶才可以用指定的用戶名和密碼登錄進入系統(tǒng)，進行權限范圍內的操作。在系統(tǒng)登錄界面中，只有輸入正確的用戶名和密碼，才能進入系統(tǒng)，進入系統(tǒng)后用戶可隨時修改自己的密碼。對用戶密碼可提供更嚴格的控制功能，如首次登錄系統(tǒng)必須修改密碼、經(jīng)過多長時間必須修改密碼、多次登錄失敗鎖定用戶等，進一步提供系統(tǒng)的身份認證安全性。2.2.7.5.2 用戶權限控制系統(tǒng)提供權限管理功能模塊，系統(tǒng)管理員可增加、刪除、修改用戶、用戶組，設置用戶的、操作權限、數(shù)據(jù)權限。通過用戶、用戶組及權限管理功能，可根據(jù)機構、部門、用戶類別等建立用戶組，用戶可以屬于某個組或幾個組，也可以是獨立用戶。通過對用戶組

32、進行授權，組中的每個用戶都擁有組的所有權限，極大方便了授權管理；獨立的用戶可以獨立授權。用戶組、用戶的權限可以針對機構、業(yè)務數(shù)據(jù)的范圍、功能范圍等進行授權，實現(xiàn)系統(tǒng)應用的數(shù)據(jù)安全。2.2.7.5.3 關鍵數(shù)據(jù)加密存儲對于存儲到系統(tǒng)中的一些關鍵敏感數(shù)據(jù)，程序對這些數(shù)據(jù)進行加密存儲，使得在其它任何軟件環(huán)境中都無法獲取明碼。2.2.7.5.4 系統(tǒng)操作處理日志系統(tǒng)對用戶登錄情況，如登錄用戶、進入時間、退出時間、操作功能項等進行自動記錄；對于數(shù)據(jù)錄入、數(shù)據(jù)同步、數(shù)據(jù)抽取和數(shù)據(jù)分析等應用處理的時間、數(shù)據(jù)范圍、執(zhí)行情況等也自動記錄日志，以便出問題時跟蹤追查審計。系統(tǒng)日志還可用于系統(tǒng)操作的防抵賴。2.2.7

33、.5.5 安全管理機構和制度建設明確系統(tǒng)的安全管理機構/部門、人員及職責，負責管理系統(tǒng)安全保密工作。制定系統(tǒng)安全保密管理制度，并嚴格加以執(zhí)行及監(jiān)督，實現(xiàn)資源的合理配置和統(tǒng)一管理，實現(xiàn)統(tǒng)一的訪問控制策略，確保系統(tǒng)的安全運行、安全審查。在外部安全上，企業(yè)級的防火墻可以為本系統(tǒng)提供一個安全的運行環(huán)境。在系統(tǒng)內部，本系統(tǒng)用戶眾多，機構、角色、權限各不相同，因此必須具有較高的安全性，防止用戶越權訪問以及竊取數(shù)據(jù)。 用戶的每個動作都要經(jīng)過身份驗證，在身份與權限匹配的情況下才能繼續(xù)執(zhí)行其他操作，就可以有效實現(xiàn)安全性目標。操作授權：對不同使用部門使用產(chǎn)品的授權和其中不同級別的用戶使用產(chǎn)品功能的授權由系統(tǒng)管理員

34、分級授權，授權信息放在數(shù)據(jù)庫中，操作員的每一個操作均需系統(tǒng)授權。3 項目管理3.1 溝通管理3.1.1 項目會議制度項目會議是服務于項目工作的，是為了更好的加強項目溝通、解決項目實施過程中存在的各種問題。每次會議都要有專人做會議記錄，會議紀要的格式參見雙方約定文檔規(guī)范中的會議紀要模板，會后由記錄人員將會議紀要分發(fā)給相關人員，并上傳版本庫中。項目組根據(jù)項目實際情況擬設立定期會議和不定期會議，分別闡述如下：3.1.1.1 定期會議 項目周例會 會議目標： 溝通項目狀態(tài)，提出項目問題、風險和依賴條件；協(xié)調項目資源；對項目提出建議，問題的解決方法，行動計劃。 日期與時間： 每周四14:00開始。 參加

35、人員： 乙方項目經(jīng)理；甲方項目經(jīng)理；項目經(jīng)理指定的其他成員。 主要議程及責任：更新項目狀態(tài)，包括：跟蹤檢查項目遺留問題的解決情況；項目狀態(tài)信息，時間進度表等；問題，風險，依賴條件（技術和管理）；對提出的問題，討論和決定行動計劃；乙方負責做會議記錄，會后分發(fā)會議記錄，將會議記錄上傳到版本庫中，并負責下一步行動計劃。3.1.1.2 不定期會議 項目狀態(tài)會議 會議目標： 使項目全體人員明確目前項目的狀態(tài)、問題、解決方法。 日期與時間：根據(jù)實際需要確定。 參加人員： 所有項目人員。 主要議程及責任：項目狀態(tài)，存在的問題及解決方法；下階段項目計劃。 項目領導組會議 會議目標： 審核下階段項目計劃；復查項

36、目狀態(tài)和里程碑；對項目中的重大問題做出決策；協(xié)調項目各方資源；解決項目各方可能發(fā)生的重大爭議。 日期與時間：根據(jù)項目進展實際情況安排。 參加人員：項目領導組成員；乙方項目經(jīng)理；甲方項目經(jīng)理；其他有需要參加的人員。 主要議程及責任：項目經(jīng)理匯報項目狀態(tài)和下階段項目計劃；項目領導討論項目中需要決策的重大問題；乙方負責做會議記錄，會后分發(fā)會議記錄，將會議記錄上傳到版本庫中，并負責下一步行動計劃。 重大問題匯報會議 會議目標： 匯報項目重大問題，并討論決定采取何行動。 日期與時間：重大問題出現(xiàn)時。 參加人員：問題發(fā)起人；項目經(jīng)理；高層領導等。 主要議程及責任：匯報項目重大問題，找出解決方案，決定行動計

37、劃。 項目組內部討論/溝通會議 會議目標：對項目組內部遇到的問題進行討論，找出解決方案，并討論決定采取何行動。 日期與時間：根據(jù)開發(fā)的狀態(tài)。 參加人員：問題發(fā)起人；溝通相關人員等。 主要議程及責任：討論出現(xiàn)的各種相關問題，找出解決方案，決定行動計劃。3.1.2 項目狀態(tài)周報制度項目組各組員每周一上午提交周報，提交到乙方項目經(jīng)理，由安訊軟件（上海）有限公司項目經(jīng)理匯總后提交給甲方項目經(jīng)理；甲方項目經(jīng)理根據(jù)項目狀態(tài)，總結項目周報，形成項目組的狀態(tài)周報，并于每周一下午4點之前上傳到版本庫中的周報目錄上。3.1.3 溝通手段 開會或直接交談按需要組織會議進行溝通，或直接找相關的人進行討論，注意記錄溝通

38、和討論結果，重要問題討論必須有書面會議記錄。 電話或電話會議通過電話的方式進行信息溝通。對比較重要的事情，需要包括開發(fā)地點以外的人員，則需要利用電話會議的方式進行討論，溝通。 電子郵件建立項目組電子郵件系統(tǒng)及與外界聯(lián)系的電子郵件系統(tǒng)。3.2 配置管理3.2.1 配置管理原則所有的項目過程文檔、代碼或項目最終文檔、代碼的編制工作，都必須在甲方提供的配置環(huán)境中進行，所有人員都必須按甲方的配置管理制度進行工作。3.2.2 配置庫管理配置庫分為文檔庫和代碼庫。文檔庫管理項目的所有文檔，而代碼庫管理項目的所有代碼，文檔及代碼庫進行基線化管理，按照項目階段，對文檔庫和代碼庫打基線。經(jīng)測試以及審核后提交產(chǎn)品

39、庫，文檔與產(chǎn)品由甲方統(tǒng)一管理，未經(jīng)甲方同意，不得對任何項進行任何更改。3.3 變更管理為了保證項目開發(fā)工作的相對穩(wěn)定性，提高工作效率，確保開發(fā)質量。對影響項目計劃的變更，制定出處理變更的規(guī)范的、統(tǒng)一的方法和過程，估算出因變更引起的相應的資源、費用、和時間的變化以及變更確立后，變更的發(fā)布，執(zhí)行，和過程質量的控制。本項目成立變更控制委員會，一般為單數(shù)組成（甲方人數(shù)乙方1），由甲方指定人員任變更控制委員會主任;變更的審批由變更控制委員會表決決定，2/3人數(shù)通過為表決通過，變更控制委員會主任有最終否決權。如變更控制委員會無法對變更做出最后決定，由變更控制委員會主任將變更申請?zhí)峤豁椖抗芾砀邔舆M行裁決。3

40、.3.1 發(fā)起變更提出變更要求必須填寫變更申請表（參見附件C“變更申請表”所附表樣）。變更申請表由變更申請人填寫。變更控制委員會審議變更申請的有效性和變更的必要性，決定拒絕變更申請或者要求乙方對申請的變更進行評估。3.3.2 評估變更乙方指定的評估人員要充分評估變更對項目整體計劃、進度、費用及質量的影響，進行全面的評估，在五工作日內，填寫變更評估表（參見附件C “變更申請表”所附表樣），以書面形式提交甲方。3.3.3 審批變更變更控制委員會對變更請求進行審批，由變更控制委員會主任簽署書面變更審批單，有效變更審批間必須在審批結論中明確是否通過變更申請。涉及合同變更的不在變更控制委員會審批范圍內，

41、根據(jù)購買合同規(guī)定的條款進行審批。3.3.4 執(zhí)行變更乙方負責根據(jù)變更審批結果，調整相關項目計劃，根據(jù)新的項目計劃和項目進度，重新分配資源，對變更展開工作，并指定變更執(zhí)行評估人員。變更有關執(zhí)行人進行變更執(zhí)行。執(zhí)行完成后向變更控制委員會報告變更執(zhí)行情況。3.3.5 變更執(zhí)行評估變更控制委員會中乙方委員負責填報變更執(zhí)行結果評估表，對執(zhí)行結果進行評估跟蹤，并將結果向變更控制委員會主任報告。3.4 質量管理3.4.1 質量規(guī)劃 質量目標：針對數(shù)據(jù)倉庫一期系統(tǒng)，確立以下質量目標，甲乙雙方應針對以下質量目標開展質量管理活動： 保證100%滿足業(yè)務需求要求的正確性與精確性 用戶滿意度達90%以上 質量管理原則

42、 客戶滿意度優(yōu)先 預防優(yōu)于檢查 管理層的責任 持續(xù)改進 質量保證計劃：合同生效后，甲乙雙方應在質量方針、質量目標、質量原則及項目范圍等的前提下建立質量保證計劃，明確相關干系人質量管理職責、項目質量管理任務的定義與責任人、需遵守的制度、規(guī)程、規(guī)范與標準、質量控制的方法、工具、記錄與跟蹤等，便以此為基礎，有效地開展質量管理活動。 測試要求測試作為項目最主要的驗證方式，應該得到雙方的高度重視。應達到以下要求： 所有測試必須有適用的測試管理流程，得到質量控制小組的確認 在需求分析階段，出具用戶測試計劃，以保證需求的可測試性 在概要設計階段，出具集成測試計劃、集成測試案例 在詳細設計階段，出具單元測試計

43、劃、單元測試案例 編碼階段所有模塊必須經(jīng)過單元測試通過，并出具單元測試報告，經(jīng)雙方項目經(jīng)理確認 集成測試計劃需經(jīng)評審通過 集成測試必須有兩輪以上的測試，每輪測試必須有集成測試報告 用戶測試必須由甲方組織測試通過，出具經(jīng)相關單位蓋章的測試報告后，視為完成 在集成測試完成后的程序修改應有足夠的回歸測試工作，并得到項目質量控制小組的確認3.4.2 質量保證甲乙雙方在項目實施期間應進行以下質量保證活動：1. 規(guī)則的培訓與指導 雙方項目經(jīng)理負責組織在項目啟動階段向項目組成員做有關制度、規(guī)程、標準、工具與模板的使用培訓。2. 文檔管理 文檔規(guī)范 文檔需遵循一定的規(guī)范，由雙方參照相關國際與國家標準協(xié)商制定，需經(jīng)甲方項目質量控制人員審核通過。 文檔標識方法必須有統(tǒng)