項目實施過程中的數據管理

項目實施過程中的數據管理

　　管理信息系統實施成功三大因素依次為：人、數據、技術，也許有些人不完全認同，但是數據的重要性是大家不可否認的。yjbys小編下面為大家整理了關于項目實施過程數據管理的文章，希望對你有所幫助！

　　1. 數據管理的組織機構的建立

　　為了更好的進行軟件系統的數據管理，應該從組織機構角度來做考慮，建立單獨的組織機構來管理數據相關工作，或者在實施小組里面專人總負責。

　　軟件開發商和客戶核心的業務骨干一起制定數據規范，客戶提供符合規范的業務數據，只有符合規范的數據才能進入系統。

　　2. 數據管理的原則

　　強調客戶和軟件開發商的2方項目組成員做到”不能有‘我以為’的思想“，一旦有如此思想，很容易陷入閉門造車，項目需求很容易走樣，因為客戶à所有的客戶，也是在‘我以為 ’。項目組要想做到控制住需求，一定要拋開自己的設想。所以任何一個項目組成員，第一句話就告訴他，不要有”我以為“的想法。把‘我以為’變成‘客戶認為 ’(最好是客戶和軟件提供商一致認為)，這才是最重要的。

　　這又回到了項目管理上。我在這里實際上只是想從數據管理這個更具體的角度來闡述問題。

　　3. 數據入口的單一性

　　同一數據必須一次、一處進入系統，保證其準確性，及時性和完整性和入口的單一性。管理控制一體化是系統的目的，如果一個數據在多個地方存儲，很容易造成數據的不一致。

　　4. 數據副本管理/數據版本管理

　　雖然上面提到了數據存儲的單一性，但是有些時候也需要存儲副本數據。存儲這些副本數據的目的就是為了在使用數據副本的地方不受到數據源的變化的影響。

　　例如：數據1在業務A進入系統，業務B使用到了數據1，但是為了避免在業務B使用了數據1后，業務A又把數據1的修改影響到業務B，那就需要業務B在使用數據1時候保存副本。

　　比如：城市拆遷資源計劃系統的拆遷合同在使用房源業務錄入的房源房屋面積信息時，就使用了副本機制，在合同使用房屋面積時候，把面積信息存儲下來，當合同構筑完成時候，如果相應的房屋面積信息發生了變動，就用另外的業務來處理這個數據變動的相應處理(比如，使用房源的差價款合同來處理)。

　　有朋友建議用配置管理系統，把數據版本機制引入了業務數據里面。做過J2EE的項目，都知道很多地方可以通過配置來進行管理。其實這個思想延伸到數據庫模型的設計時候，就體現出來了業務數據的配置管理的思想的使用。

　　我們其實也有是用這個思想，但是主要體現在 在基于數據表級別上用數據級別+歷史編號 來識別有效的數據。1個很簡單的例子：

　　一個員工的姓名原來 是aa, 后來改委bb，可以通過歷史編號 找到原來 的信息是bb通過數據級別識別現在的有效數據是aa，我們把數據版本控制更多的是采用‘數據級別’加‘歷史編號’另外還加上了一個‘生效日期’， ‘截止日期’這2個時間戳另外，實際軟件系統的歷史業務數據進入系統就比較煩，可能需要使用版本管理機制來處理才行得通。

　　5.建立數據等級制度

　　軟件項目實施中業務規則經常會陷入一個兩難的境地，如果業務規則加強，很多數據數據達不到規范化的要求，無法入機;如果放寬控制，很多垃圾數據就進入了，大家都明白一個道理，對于軟件系統，垃圾數據進去，肯定是垃圾數據出來，統計查詢結果肯定是這樣的。

　　可以建立數據的等級制度，制定數據進入系統的最低要求。達到最低要求才能進入系統，比如：

　　業務A,需要數據a1,數據a2,,數據a3, 數據4。我們可以制定進入系統的關于業務A的條件是必須要有數據a1,a2才可以進入系統(也就是最低要求)，如果提供的業務數據同時有數據a1,數據 a2, ,數據a3,那就是更高一級的數據(第二級數據)，如果業務數據在滿足第二級數據的基礎上，提供了數據4，那就是第三級數據。

　　如果用過J2EE平臺的同行理解起來就比較容易，這實際上就是JMS基于主題的消息管理思想用于軟件系統一個具體例子而已，這里不過是強調的是用于管理數據的信任等級而已。

　　其實很多軟件項目開始制定的的數據規范，一般到后來都執行不下去，主要是太理想化了，也許只有到系統真正用起來了，系統數據的信任等級才能上去。所以我覺 得應該在系統開始時候就把數據分等級，不同的等級，業務給與適當不同的處理，這樣也便于后期的業務進行查詢統計分析或者數據挖掘。

　　這種思想實際上就是將數據可以信任的程度進行分類;而一般的軟件系統是把數據定義為兩類，可以進入系統，不可以進入系統;我在這里設想的是，從數據可以信 任的角度出發，分成多種類別，使用了一個小數來描述信任程度，而不是一個二值邏輯變量來描述;這樣從建立軟件系統整體模型的時候，把數據信任管理納入考慮 之內，在進一步作業務分析，決策支持或者數據挖掘時候是比較有好處的;當然進一步延伸可能就需要從OLTP/OLAP混合建模來考慮，不過真要到那個高 度，可能項目范圍就擴大了很多，具體怎樣操作，還要看項目具體情形。

　　當然，在軟件項目實際操作的時候，可能還會遇到另外一個問題，很可能用戶會亂用這個數據信任程度的概念，我個人的建議是在項目實施中如果可能的話，優先進 入信任等級高的數據，然后才是信任程度低的數據;當然也可以從人員來角度作為切入點，信任等級越低的數據，進入系統就需要的業務更熟悉的人員來操作錄入， 而且經過的業務處理步驟就越多。一句話，數據信任程度越低，就應該受到的審查/檢察越多。

　　在現實中稍微規模大一點的軟件系統涉及到的組織機構都是比較大的，有很多還可能是松散的組織管理模式。在這類組織機構中，同樣的業務數據可能很多部門都會是數據錄入點和數據分析點，為此可以從數據采集/來源角度來描述數據本身。

　　從當前項目利益來說，數據來源管理方便數據查詢分類，長期來說可以建立起數據信任等級。

　　對于數據來源的識別，一般需要有特定信息來記錄數據的來源，特別是一些大型企業當然分支機構較多的公司企業政府，也應該這樣來管理。

　　事實上，數據來源管理是數據信任管理的進一步延伸，是數據信任管理的前置條件。一個數據，可以是來自于A部門的也可能是來自于B部門的。為了方便統計查詢和數據信任管理的加強，應該記錄下數據的來源地。

　　6.具體操方式可以有以下幾種：

　　1) 數據錄入人員的工作人員編號，知道了數據錄入人員的編號，就知道數據的來源地。

　　當然，實際工作種存在人員調動，替操作(1個人用另外一個人的身份進入系統數錄入)，這些都有可能需要考慮到，否則可能造成數據來源管理失效。

　　2)另外一種方式就是直接記錄數據錄入的部門編號。

　　這種方式弊端就是不能記錄下數據的具體操作人員。

　　其它說明：如果系統中引入了工作流產品，數據來源這部分工作可以由工作流來擔任。具體例子：在現實的軟件系統中可能存在一個主數據庫/數據中心，若干分數 據庫/數據中心，系統在每過一定時間進行數據上傳/下載，為了進行數據合并和控制數據的修改，應該每個分數據中心只能處理修改自己的數據，可以查詢總數據 中心/其他分數據中心的數據。如果沒有引入數據來源管理(數據屬地管理)和數據版本的控制機制，不知道系統在作數據中心合并會怎樣子?

　　7.數據項的分類編碼

　　數據項的分類編碼，實際上是數據項來源管理的一個具體延伸。數據項編碼的目的就是更快更好的識別數據代表的業務意思。一個典型的例子就是ERP中的BOM表(基本物料清單)。

　　數據項的分類編碼，不只是在系統模型建立上有指導意義，在進入系統的業務數據的規范化同樣有指導意義。

　　數據項的業務編碼和系統編碼分離。業務編碼很多時候只是為了識別業務數據的需要，很難保證業務數據的唯一性要求。而且業務編碼可能會發生變動，有些單位的 總體規劃從調研到討論制訂、到項目審批通過，再到最終實施，常常幾年過去了，需求發生變化，這種編碼規則不發生變動幾乎不可能。2000年我參與的一個企 業軟件系統，就一個產品編碼規則2個月就發生了5次變動。從更長的時間范圍內來說，應該考慮數據產生時期問題，不同時間階段產生的業務數據，使用的業務規 則不一樣，數據編碼這個層次很多時候很難識別數據當時的業務環境。

　　以一個簡單的例子來說明：

　　業務數據表的primary key系統應該是系統定義的，而數據項的業務編碼只能作為索引或者備用鍵使用，這樣就減少了數據業務編碼規則的變動對系統影響減少到更小的程度。

　　8.算法的版本化

　　本來我打算在前面的基礎上，再談一下業務流程的管理設置問題，不過，現在工作流思想深入人心，我也就跳過了。我打算從數據的核心業務處理，算法處理角度來闡述。

　　其實在現實中的軟件項目中，大家提到的較多的BPR,工作流這些東西，但是很少提到算法這個單詞。當然，不可否認，很多軟件項目，特別是電子政務/OA的 業務主要是體現在流程/文件上，算法這部分比較簡單(當然，我這樣說，有人可能不認可，暫且就不爭論它了)，就沒有必要去強調算法的重要性了。

　　為了避免垃圾數據進入系統，垃圾數據出來，有必要對數據進行分類管理。正如前面提到的那樣，對于進入系統的數據，進行信任等級劃分，數據來源的分類;但是 對于系統出口，為了避免出現垃圾數據，需要在數據處理階段，也要進行分類處理，這里就引入了算法的版本化，來適應不同的數據/業務需要。

　　在實際項目中，可能不同信任等級的數據，采用不同的算法去處理數據，這樣才使得數據的處理更有針對性，更符合實際需要。

　　從需求變更的角度出發，軟件開發商可以先實現一些數據信任程度低的算法，然后再根據項目實際情況，決定是否實現更高一級數據等級的算法。在現實軟件項目， 數據信任等級低的采用的算法也會簡單一些，由于需求變更，增加了新的數據信任等級更高的數據，這時候可以考慮暫時采用低等級的算法進行處理，然后再結合人 工干預，達到數據處理的要求。大家都明白一點，算法復雜，測試的難度就大，但是使用這些更高等級的算法的幾率是很少的，處于成本的原因可以把這些算法的實 現滯后。

　　當然我這樣說，并不是意味著放棄高等級的算法，一些根據項目實際情形需要來操作。

　　數據根據信任程度分成等級，呵呵，這就是所謂工廠方法模式嘛，算法也分成等級結構，這就是所謂的模板方法模式。

　　數據在處理后，應該記錄下被使用的算法版本，這樣才便于以后統計查詢分析或者數據挖掘之類工作的開展。

　　例如：在一個商品交易中，一個商品可能被購買的價格是正常價格，節假日優惠價，會員優惠價，在交易流水賬中，應該記錄下交易時候是采用的那個價格類型，原始價格多少，實際購買價格多少。記錄下原始價格，是因為，商品的原始價格本身可能是變化的。

　　再以拆遷資源計劃系統為例，房屋補償的價格價格可能是來自于管理參數，也可能是來自于申請，實際到底是來自于哪個，算法應該記錄下來。

　　9.業務規則使用的版本化

　　前面已經提到了數據錄入的版本化，還有算法的版本化，也就是計算結果的版本化。但是還沒有談到一點，到底啥時間該采用哪個版本算法。

　　在J2EE項目中，一般是采用配置文件的方式來控制版本。從配置管理角度的來說，一切都根據配置文件來決定使用哪個版本的數據錄入的分級(數據信任程度分級)，然后根據配置文件決定數據處理使用的算法版本。

　　其實在J2EE項目中，可以采用類似apache commons-validator這樣的包，來進行數據錄入的信任等級建立。

　　前面都已經提到了從工廠方法模式的角度來建立數據信任等級制度，但是并沒有解決到底啥時間采用哪個方法處理數據。也許有人建議，采用工廠方法模式的思想， 把數據當成產品，把算法當成工廠，來處理(注意：不是制造)數據。這個想法也許能夠滿足一些系統的需要，但是更多時候是失效。

　　為此，我覺得有必要把算法的分配使用當成為一個業務管理策略來管理，通過單獨的業務模塊去設置業務的算法管理策略，可以把這些策略保存為配置文件或者直接 保存到數據表;在J2EE項目中，常用的方式使用XML的格式保存為配置文件，但是如果這個策略比較復雜的時候建議還是保存到數據表。

【項目實施過程中的數據管理】相關文章：

如何實施高效的項目管理06-20

工程實施階段項目管理10-23

項目管理方法和項目實施方法的關系01-11

物流企業實施項目管理的步驟12-26

項目管理師《項目實施》臨考試題07-26

監理工程師在項目監理過程中的控制方法01-09

實施OA辦公自動化過程中值得注意的問題06-13

2017投資項目管理師考試《項目實施》練習題及答案05-13

ERP在實施財務管理的過程中易發的失誤10-25